Messaging system and method with dead man switching

ABSTRACT

A messaging system and method with dead man switching providing for hierarchical delivery of messages based on selected message hierarchy levels with controlled delivery/response timing is disclosed. The system and method incorporates a messaging host that communicates with a messaging source client that creates and prioritizes a message and targets address(es) for the message. This message is then transmitted to the target address(es) using a hierarchical transmission thread having set limits on response times for each address within the thread. Reception of the message by each target(s) produces visual and/or auditory notification at the target(s). Messages are automatically forwarded to remaining target(s) within the thread upon expiration of a timer should the target(s) fail to respond to the message within a predetermined time. Failure of the target(s) to respond to the message(s) is reported bi-directionally along the thread and forwarded to remaining target(s) in the thread.

CROSS REFERENCE TO RELATED APPLICATIONS

Applicants claim benefit pursuant to 35 U.S.C. §119 and herebyincorporates by reference Provisional Patent Application for “MESSAGINGSYSTEM AND METHOD WITH DEAD MAN SWITCHING”, Ser. No. 61/459,931, filedDec. 20, 2010, and submitted to the USPTO with Express Mail on Dec. 20,2010 with tracking number EB483477834US.

PARTIAL WAIVER OF COPYRIGHT

All of the material in this patent application is subject to copyrightprotection under the copyright laws of the United States and of othercountries. As of the first effective filing date of the presentapplication, this material is protected as unpublished material.

However, permission to copy this material is hereby granted to theextent that the copyright owner has no objection to the facsimilereproduction by anyone of the patent documentation or patent disclosure,as it appears in the United States Patent and Trademark Office patentfile or records, but otherwise reserves all copyright rights whatsoever.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not Applicable

REFERENCE TO A MICROFICHE APPENDIX

Not Applicable

FIELD OF THE INVENTION

The present invention is related to the field of computer messagingsystems incorporating severity and urgency protocols to ensure deliveryof time sensitive information to appropriate personnel or automatedinformation systems. Included within the scope of this field is theability to convert from a variety of mobile device messaging systems tocomputerized text and visa-versa, thus integrating smartphone/mobiledevice communications within the overall framework of computerizedcommunications. Within this context the present invention promotesabsolute delivery of information, within a client designated path anddesignated timeframe, and also incorporating auto-forwarding featuresand detection of offline receivers and/or receiver response timeouts.

DESCRIPTION OF THE PRIOR ART

The field of prior art associated with computer messaging includes theuse of electronic mail (EMAIL) and text messaging (TEXT) that are bothintegrated into a wide variety of computer information frameworks. Bothof these systems incorporate store-and-forward messaging technologies toroute messages to a target destination from a messaging source, andgenerally rely on PULL of data from servers. While multiple recipientsare possible in both existing paradigms, little if any automatedfeedback or chronological tracking of message transmission is performedin either system.

DEFICIENCIES IN THE PRIOR ART

Traditionally, these message transmission systems lack a high degree ofsecurity and can be “hacked” to uncover information contained within themessages. Furthermore, there is generally no assurance that once amessage is sent that its intended recipients have received the messageor that they have read it or acted on it. In situations where theinformation is of a critical nature and must be acted on promptly, often“broadcast” messages are issued to a number of individuals, hoping thatone of these individuals will act on the information contained in themessage to avert injury to or loss of human life or destruction ofproperty, etc.

However, even with the use of broadcast messaging there is no assurancethat the message will be received or acted on appropriately. For thisreason, the prior art approaches to the handling of messagesincorporating a scaled severity level and urgency level are insufficientto ensure proper action on the message. As such, the prior art fails toaddress this need within the computer messaging community.

Generally speaking, prior art technologies rely on PULL data techniques,rather than PUSHing data to the user terminal interface. This results inunacceptable delays in many circumstances involving time criticalapplications or events.

Traditional EMAIL systems permit the receiver to ignore the incomingmessage, or alternatively to fail to open the message or attachment.This can result in unacceptable delays in responding to critical eventsthat must be addressed by management on an immediate basis.Additionally, there is generally no logging of message events and thefailure of the recipient to deal with the message and its contents.

Within the context of messaging systems, the prior art does notgenerally teach the use of a secure and centralized messaging facilityincorporating hierarchical guarantees of message reception and action bymessage recipients based on message severity and urgency.

OBJECTIVES OF THE INVENTION

The present invention, while not being limited by the following list,can in some embodiments achieve one or more of the following objectives:

-   -   To provide a messaging system and method which has all of the        advantages of the prior art and none of the disadvantages.    -   To provide a messaging system and method that incorporates        message severity levels.    -   To provide a messaging system and method that incorporates        message urgency levels.    -   To provide a messaging system and method that incorporates        customizable client specified severity and urgency levels.    -   To provide a messaging system and method that provides for        hierarchical message routing.    -   To provide a messaging system and method that provides for dead        man switching to ensure routing of messages to proper        individuals within a hierarchy.    -   To provide a messaging system and method that provides for timed        message delivery.    -   To provide a messaging system and method that provides for        absolute certainty of message delivery.    -   To provide a messaging system and method that provides PUSH data        transmission to the message receiver.    -   To provide a messaging system and method that provides for        logging of recipient activity associated with message reception.    -   To provide a messaging system and method that provides for        logging of recipient activity associated with the message both        upstream and downstream from the message recipients list.    -   To provide a messaging system and method that provides for        mandatory action by the recipient on the message contents.    -   To provide a messaging system and method that provides for        audible/visual status indicators of message reception.    -   To provide a messaging system and method that provides for        active participation by the recipient in the message reception        process.    -   To provide a messaging system and method that provides for        maximum message delivery and response timing.    -   To provide a messaging system and method that provides for        positive transmission of a message that cannot be stopped or        redirected by the recipient.    -   To provide a messaging system and method that provides for        secure message encryption and decryption during transmission to        the recipient.

Other objects, features, and advantages of the present invention willbecome more readily apparent from the following detailed description ofthe preferred embodiment when considered with the attached drawings andappended claims.

While these objectives should not be understood to limit the teachingsof the present invention, in general these objectives are achieved inpart or in whole by the disclosed invention that is discussed in thefollowing sections. One skilled in the art will no doubt be able toselect aspects of the present invention as disclosed to affect anycombination of the objectives described above.

BRIEF SUMMARY OF THE INVENTION

The present invention utilizes a “dead man” message switchingmethodology to ensure that messages sent to a particular recipient areindeed reviewed by the recipient. A given message is associated with ahierarchical target message address list that identifies a number ofindividuals and/or organizations that will sequentially receive themessage if a higher priority individual on the list fails to respond tothe message within a predetermined amount of time. In this fashion, thedelivery of the message is always confirmed, regardless of the responsestatus of the recipient. In this manner, critical messages can beforwarded to a sequential stream of responsible individuals and feedbackcan be received by the message source user to determine if the personsultimately responsible for action on the message have indeed receivedthe message and are acting on its contents.

The system and method described herein incorporate timed responsetriggers for each level of target user within the message targetinghierarchy to ensure that message latencies are appropriate both for thetarget individual and the overall delay in acting on the message. Avariety of message severities and urgencies can be associated with themessage to automatically modify the timing latencies associated withmessage response to ensure an overall optimum response to the messagebased on its declared importance.

The use of “dead man” switching to retransmit messages to otherindividuals within the target message hierarchy thread ensures a degreeof assured message delivery and response not available with the priorart messaging methodologies. This functionality, in conjunction withsecure message transmission and optional plug-in software and/orhardware modules, permits the present invention to provide a widevariety of time-critical and mission-critical message deliverymechanisms that are not addressed by the prior art.

BRIEF DESCRIPTION OF THE DRAWINGS

For a fuller understanding of the advantages provided by the presentinvention, reference should be made to the following detaileddescription together with the accompanying drawings wherein:

FIG. 1 illustrates a general preferred exemplary embodiment systemarchitecture of the present invention;

FIG. 2 illustrates a general preferred exemplary embodiment methodarchitecture of the present invention;

FIG. 3 illustrates a general preferred exemplary embodiment systemoverview of the present invention;

FIG. 4 illustrates a general preferred exemplary embodiment methodoverview of the present invention;

FIG. 5 illustrates a preferred exemplary embodiment top level systemoverview of the present invention;

FIG. 6 illustrates a preferred exemplary embodiment top level methodoverview of the present invention;

FIG. 7 illustrates an exemplary expanded system network layout for somepreferred exemplary embodiments of the present invention;

FIG. 8 illustrates an exemplary expanded system network layout for somepreferred exemplary embodiments of the present invention;

FIG. 9 illustrates an exemplary parallel message transport methodologyuseful in some preferred embodiments of the present invention;

FIG. 10 illustrates an exemplary cascade message transport methodologyuseful in some preferred embodiments of the present invention;

FIG. 11 illustrates an exemplary parallel/cascade message transportmethodology useful in some preferred embodiments of the presentinvention;

FIG. 12 illustrates an exemplary cascade/parallel message transportmethodology useful in some preferred embodiments of the presentinvention;

FIG. 13 illustrates a preferred exemplary embodiment of the presentinvention utilizing message delivery auto-forward timeouts;

FIG. 14 illustrates a preferred exemplary embodiment of the presentinvention utilizing anticipatory message queuing (AMQ);

FIG. 15 illustrates an alternate preferred exemplary embodiment of thepresent invention utilizing anticipatory message queuing (AMQ);

FIG. 16 illustrates an autonomous preferred exemplary embodiment of thepresent invention utilizing anticipatory message queuing (AMQ);

FIG. 17 illustrates an exemplary system embodiment illustrating the useof a decision matrix to determine message routing;

FIG. 18 illustrates an exemplary method embodiment illustrating the useof a decision matrix to determine message routing;

FIG. 19 illustrates an exemplary Boolean syntax that may be used in somepreferred invention system/method embodiments as the basis for therouting decision matrix evaluation;

FIG. 20 illustrates a preferred system embodiment employing a CA/usermanagement architecture;

FIG. 21 illustrates a preferred exemplary message definitionarchitecture used in some preferred embodiments of the presentinvention;

FIG. 22 illustrates an exemplary message definition form;

FIG. 23 illustrates an exemplary message delivery hierarchy map used ingenerating a message definition form;

FIG. 24 illustrates an exemplary message originator method used in somepreferred embodiments of the present invention;

FIG. 25 illustrates an exemplary Message Originator/Recipient LoginValidation Method used in some preferred embodiments of the presentinvention;

FIG. 26 illustrates an exemplary Message Routing/Delivery Method used insome preferred embodiments of the present invention;

FIG. 27 illustrates an exemplary On-The-Fly Message Transport Methodused in some preferred embodiments of the present invention;

FIG. 28 illustrates an exemplary On-The-Fly Transport Detail Method usedin some preferred embodiments of the present invention;

FIG. 29 illustrates an exemplary On-The-Fly Transport Detail Method usedin some preferred embodiments of the present invention;

FIG. 30 illustrates an exemplary Message File Attachment Method used insome preferred embodiments of the present invention;

FIG. 31 illustrates an Anonymous Message Interrogator Method used insome preferred embodiments of the present invention;

FIG. 32 illustrates an exemplary Message Arrival Method used in somepreferred embodiments of the present invention;

FIG. 33 illustrates an exemplary software plug-in API systemarchitecture used in some preferred embodiments of the presentinvention;

FIG. 34 illustrates an exemplary hardware plug-in API systemarchitecture used in some preferred embodiments of the presentinvention;

FIG. 35 illustrates an exemplary secure scanner hardware architectureused in some preferred embodiments of the present invention;

FIG. 36 illustrates an exemplary secure scanner method used in somepreferred embodiments of the present invention;

FIG. 37 illustrates an exemplary system embodiment employing a PLCplug-in API;

FIG. 38 illustrates an exemplary system embodiment employing a licensingplug-in API;

FIG. 39 illustrates the user of mobile devices and Multiprotocol LabelSwitching (MPLS) within the context of the present invention;

FIG. 40 illustrates an exemplary mobile login application dialog used insome preferred embodiments of the present invention;

FIG. 41 illustrates an exemplary login screen useful in some preferredembodiments of the present invention;

FIG. 42 illustrates an exemplary CA authentication screen useful in somepreferred embodiments of the present invention;

FIG. 43 illustrates an exemplary CA steady state screen useful in somepreferred embodiments of the present invention;

FIG. 44 illustrates an exemplary CA Create Message screen useful in somepreferred embodiments of the present invention;

FIG. 45 illustrates an exemplary CA Severity screen useful in somepreferred embodiments of the present invention;

FIG. 46 illustrates an exemplary CA Urgency screen useful in somepreferred embodiments of the present invention;

FIG. 47 illustrates an exemplary CA Reply To Message screen useful insome preferred embodiments of the present invention;

FIG. 48 illustrates an exemplary CA History screen useful in somepreferred embodiments of the present invention;

FIG. 49 illustrates an exemplary user definition dialog used in somepreferred embodiments of the present invention;

FIG. 50 illustrates an exemplary user definition dialog used in somepreferred embodiments of the present invention;

FIG. 51 illustrates an exemplary user definition dialog used in somepreferred embodiments of the present invention;

FIG. 52 illustrates an exemplary user definition dialog used in somepreferred embodiments of the present invention;

FIG. 53 illustrates an exemplary user login screen useful in somepreferred embodiments of the present invention;

FIG. 54 illustrates an exemplary steady state messaging dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 55 illustrates an exemplary standard severity dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 56 illustrates an exemplary executive severity dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 57 illustrates an exemplary standard urgency dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 58 illustrates an exemplary executive urgency dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 59 illustrates an exemplary Create Message dashboard dialog screenuseful in some preferred embodiments of the present invention;

FIG. 60 illustrates an exemplary Reply To Message dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 61 illustrates an exemplary Read Message Update dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 62 illustrates an exemplary History dashboard dialog screen usefulin some preferred embodiments of the present invention;

FIG. 63 illustrates an exemplary On-The-Fly Message dashboard dialogscreen useful in some preferred embodiments of the present invention;

FIG. 64 illustrates an exemplary File Attachment dashboard dialog screenuseful in some preferred embodiments of the present invention.

DESCRIPTION OF THE PRESENTLY PREFERRED EXEMPLARY EMBODIMENTS

While the present invention is susceptible of embodiment in manydifferent forms, there is shown in the drawings and will herein bedescribed in detailed preferred embodiment of the present invention withthe understanding that the present disclosure is to be considered as anexemplification of the principles of the present invention and is notintended to limit the broad aspect of the present invention to theembodiment illustrated.

The numerous innovative teachings of the present application will bedescribed with particular reference to the presently preferredembodiment, wherein these innovative teachings are advantageouslyapplied to the particular problems of a MESSAGING SYSTEM AND METHOD WITHDEAD MAN SWITCHING. However, it should be understood that thisembodiment is only one example of the many advantageous uses of theinnovative teachings herein. In general, statements made in thespecification of the present application do not necessarily limit any ofthe various claimed inventions. Moreover, some statements may apply tosome inventive features but not to others.

Communications Network not Limitive

The present invention anticipates that many preferred embodiments maymake use of the Internet to communicate messages and control structuresamong various system components. However, the present invention shouldbe interpreted to broadly define the term “communications” to includeall communication means including but not limited to the Internet. Thisdefinition also includes local or private networks that are not publiclyaccessible.

System Interface not Limitive

The present invention anticipates that many preferred embodiments maymake use of personal computers and other networked devices with displayscreens to act as the system interfaces for human interaction within thecontext of the disclosed invention. However, the term “interface” as itapplies to a human interface within the context of the present inventionshould be broadly interpreted to mean any means for communicating withan individual. This might (for example) include screen displays and thelike as well as lights and other visual indicia, sirens, klaxons (andother audible indicia), as well as vibratory means. Generally speaking,the interface selected will depend on a wide variety of factors known tothose of skill in the art depending on the environment in which theparticular invention embodiment is applied. Generally speaking, itshould be noted that many present invention preferred embodimentsspecifically anticipate that personal computers (PCs), standalone fileservers, and mobile (wireless) telephones (including but not limited tosmartphones, mobile devices, computer-operated phones, and the like)will operate as the message processing hosts and/or sources/targetswithin the context of this disclosure.

Severity/Urgency not Limitive

The present invention anticipates that messages may be routed andidentified based on severity levels and/or urgency levels. However, thepresent invention anticipates that these two broad categories are notlimitive of the classifications and identifications that may be given toa particular message. The present invention specifically anticipatesthat a wide variety of other message “tags” and classifications may beassociated with a given message in order to ensure that it is routed toand acted on by appropriate individuals within the hierarchical targetmessage thread.

Customizable Hierarchy/Status Levels not Limitive

The present invention anticipates that the generic “tags” illustratedabove in the severity/urgency level description may be made fullycustomizable to meet client needs. As stated previously there is nolimitation on two-level severity/urgency tagging of messages, thesystem/method may incorporate a plethora of customizable messagecategory hierarchy levels, with each category hierarchy level containingone or more hierarchy status markers. The category hierarchy levels andthe hierarchy status markers may be fixed or individually customizable.

Severity Levels not Limitive

The present invention anticipates that messages may be routed andidentified based on severity levels comprising SEVERE, SERIOUS,MODERATE, MINOR, and/or ANONYMOUS classifications. The present inventionspecifically anticipates that this list of classifications may be largeror smaller than this list and teaches that this list is only exemplaryof some preferred embodiments of the present invention. One skilled inthe art will recognize that this list may be contracted or expanded in awide variety of ways to address the messaging needs of a particularembodiment implementation.

Urgency Levels not Limitive

The present invention anticipates that messages may be routed andidentified based on urgency levels comprising IMMEDIATE, URGENT, NEEDSOON, INFORMATIONAL ONLY, and/or ANONYMOUS classifications. The presentinvention specifically anticipates that this list of classifications maybe larger or smaller than this list and teaches that this list is onlyexemplary of some preferred embodiments of the present invention. Oneskilled in the art will recognize that this list may be contracted orexpanded in a wide variety of ways to address the messaging needs of aparticular embodiment implementation.

Encryption not Limitive

Many presently preferred embodiments utilize a variety of military grade64-bit encryption algorithms that are commonly known to those skilled inthe art, but one skilled in the art will recognize that longerencryption keys may be utilized and that there are a wide variety ofencryption technologies available for use in this application, with noloss of generality in the teachings of the present invention.

Message Security not Limitive

Many presently preferred embodiments anticipate that custom softwareand/or other security measures may be installed at target systeminterfaces to ensure that messages received by these target systeminterfaces are held secure. This could include elements of physicalsecurity as well as software to prevent message copying (printing,screen shots, transfer to cut-and-paste buffers, etc.) from occurringand thus compromising message security. While many operating systemscurrently do not have this capability currently, the present inventionanticipates that these restrictions may be lifted in the future.

The present invention teaches the use of a hierarchical messagetransmission thread to sequentially (or in parallel) send a message to aseries of target system interfaces for presentation to end users.However, the system also anticipates the use of ancillary polling oftarget system interfaces to determine if they are in factonline/available, and if not, these target system interfaces can beeliminated (skipped) from consideration for message transfers.

Hierarchical Message Transmission Thread not Limitive

The hierarchical message transmission thread described herein maycontain a plethora of target source interface addresses contained in avariety of physical formats and information pathway names. This listlength is limited only by specific implementation of a particularembodiment and the present invention makes no limitation on this length.Furthermore, the response time values associated with each leg of thehierarchical message transmission thread may be individually set and arenot necessarily uniform. The hierarchical message transmission threadmay be augmented with conditional branching requirements to permitbranching to other hierarchical message transmission threads based onrequirements made by the message sourcing process.

Dashboard not Limitive

The present invention in some preferred embodiments utilizes“dashboards” to describe the graphical user interface to the messagingsystem/method detailed herein. This term should be broadly construed toincorporate any human interface device to a computer communicationsnetwork, but is currently though to optimally encompass any form of GUIhuman and/or machine interface.

Color Indicia not Limitive

The present invention in some preferred embodiments utilizes a varietyof colors that are associated with message severity and/or urgencyclassifications. While it is anticipated that some color combinationswill be optimal for conveying message severity/urgency levels to themessage recipients, no limitation on the range of color schemes is to beconstrued by the use of color in message presentation.

Message Fixation not Limitive

The present invention in many preferred embodiments utilizes a “fire andforget” methodology in transmission of messages in that once a messageis transmitted, its content cannot be modified and its targetdestination delivery hierarchy cannot be modified. While the currentlypreferred embodiments prohibit message modification and/or changing ofmessage recipients, some alternate embodiments anticipate that thesefeatures may be implemented in some alternately preferred embodiments.

Coherent Thread Delivery not Limitive

The present invention in many preferred embodiments assumes that themessage delivery thread hierarchy is fully defined such that there isnever a “message delivery failure” in the context of a transmittedmessage never reaching and being acknowledged by at least one messagerecipient. However, some alternative embodiments may utilize messagehierarchy threads that permit “dead” messages to be acknowledged as“undeliverable” if none of the targeted message recipients are availableor capable of acknowledging the message.

Message Delivery Failure not Limitive

The present invention in many preferred embodiments assumes that thetransmitted message is properly delivered to a recipient such that amessage delivery “failure” is only noticed to the message originatorwhen (a) the message is auto-forwarded or (b) the message originatorviews (via a mouse or other instrument) the status of a giventransmitted message. Other forms of message delivery “failure” arepossible, providing for more robust status information to be relayed tothe message originator (and possibly inter-stage message recipients).Thus, the present invention while preferring a limited message delivery“failure” definition, may incorporate a wide variant of status andreporting mechanisms to track messages transmitted by the messageoriginator.

Message Logging not Limitive

The present invention in many preferred embodiments reports anauto-forwarded message to all previous message recipients in the messagedelivery hierarchy (including the message originator), as well aslogging the auto-forward condition to a log file. While this form ofauto-forward status notification it though to be optimal, the presentinvention does not limit the scope of auto-forward status to thisparticular type of notification.

File Attachment Methodology not Limitive

The present invention in many preferred embodiments stores fileattachments on a central server and utilizes links to this server topermit message recipients to download and review these files, thepresent invention is not limited to this particular methodology of fileattachment.

General System Architecture (0100)

The most general system overview of the present invention can beunderstood by the generalized system block structure illustrated in FIG.1 (0100). In this generalized system structure, the message originator(0110) interfaces with a message entry interface (0101) under control ofa communication process (0102) managed on a communication server (0103)that typically operates under control of software derived from acomputer-readable medium (0104). Once a message has been entered by themessage originator (0110) into the message entry interface (0101), it isthen communicated using a communications network (0105) under control ofthe communications process (0102) and associated communications server(0103) to a remote client presentation interface (0106) forreview/acceptance by a message recipient (0111).

This generalized system overview anticipates that there may be aplethora of client presentation interfaces (0106, 0107, 0108) eachhaving one or more associated message recipients (0111, 0112, 0113). Thepremise behind the system as a whole is that the individual clientpresentation interfaces (0106, 0107, 0108) may or may not be availablefor message delivery. Additionally, the message recipients (0111, 0112,0113) may be unavailable to review/accept the delivered messages. Ineither of these circumstances the transmitted messages must be acted onby appropriate message recipients (0111, 0112, 0113), so thecommunications process (0102) and associated server (0103) ensure thatmessage delivery is completed to some message recipient (0111, 0112,0113) in these circumstances with confirmation of message deliverydelivered to the message originator (0110) via the message entryinterface (0101) using modified message status indicators.

In some situations the communication process (0102) in order to ensuresecure communications will operate independently of the message entryterminal (0101) and utilize the message entry terminal (0101) merely asa data entry portal to the message transmission system. One skilled inthe art will recognize that the particular hardware interfacesillustrated in FIG. 1 (0100) are exemplary in nature and that anycombination of wired and/or wireless message entry terminals (0101)and/or client presentation interfaces (0106, 0107, 0108) are possiblewith this generalized invention system structure.

As with the communication server (0103), the client presentationinterfaces (0106, 0107, 0108) may incorporate software that controls theoperation of these devices, with the software comprising computerinstructions residing on non-transitory computer readable medium (0109).Each client presentation interface (0106, 0107, 0108) may be implementedusing different hardware platforms and thus it is anticipated that thecomputer instructions residing on non-transitory computer readablemedium (0109) may take a wide variety of forms depending on the hardwareplatform.

Structurally, the system illustrated in FIG. 1 (0100) can be describedas a messaging system with dead man switching, comprising:

-   -   (a) message entry interface (0101);    -   (b) communication process (0102);    -   (c) communication server (0103);    -   (d) non-transitory computer readable medium incorporating        computer instructions implementing the communication process        (0104);    -   (e) communication network (0105); and    -   (f) client presentation interface (0106);    -   wherein    -   the message entry interface (0101) accepts messages from a        message originator (0110);    -   the messages are processed by the communication process (0102)        under control of the communication server (0103) to form        messages for transmission to a message recipient (0111);    -   the messages are transmitted over the communications network        (0105) by the communication server (0103) to the client        presentation interface (0106);    -   the client presentation interface (0106) presents the message to        a message recipient (0111);    -   the communication server (0103) attempts transmission of the        message to alternate client presentation interfaces (0107, 0108)        and/or alternate message recipients (0112, 0113) if the message        is undeliverable to the message recipient (0111); and    -   the communication server (0103) confirms delivery of the message        via the message entry interface (0101) to the message originator        (0110).

Key to this description is the ability of the described invention toguarantee message delivery to the appropriate message recipient andappropriately inform the message originator of message reception andacknowledgement by the message recipient. This capability is essentialto ensure that messages that are of a mission-critical and/orlife-critical nature are appropriately received and acted upon byappropriate message recipients.

General Method Architecture (0200)

Given the foregoing teachings of the present invention systemcomponents, the generalized method architecture for the presentinvention can be viewed as described in FIG. 2 (0200). In this context,the dead man messaging method comprises the following steps:

-   -   (1) Accepting a message at the message entry interface from a        message originator (0201);    -   (2) Storing the message on a communication server using a        communication process (0202);    -   (3) Queuing the message on the communication server for        transmission to a message recipient (0203);    -   (4) Attempting to transmit the message to a target client        presentation interface associated with a currently targeted        message recipient (0204);    -   (5) Determining if the message transmission was successful, and        if so, proceeding to step (8) (0205);    -   (6) Reporting a message transmission failure to the message        entry interface (0206);    -   (7) Selecting an alternate next target message recipient and        associated target client presentation interface and proceeding        to step (4) (0207); and    -   (8) Verifying that the message was accepted/read by the target        message recipient (0208);    -   (9) determining if the message was accepted/read by the target        message recipient, and if not, proceeding to the step (6)        (0209);    -   (10) reporting the message was received to the message entry        interface (0210); and    -   (11) terminating the dead man messaging method (0211).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

An alternate generalized system overview of the present invention isalso depicted in FIG. 3 (0300), wherein the messaging system interfaceswith a message originator (0301) that interacts with a software userinterface (0302) running under control of a computer system (0303) withapplication software contained on a non-transitory computer readablemedium (0304). The user interface (0302) collects message content anddelivery information from the message originator (0301) and processesthis via a message routing and delivery process (0305) through acommunications network (0306) to a remote messaging hardware interface(0307). The messaging hardware interface (0307) presents the messageinformation to one or more message recipients (0311, 0321, 0329) thatmay be configured in a linear vector (0311) or nested (0321, 0329)configuration.

The goal of the message routing/delivery process (0305) is to ensurethat messages entered by the message originator (0301) through the userinterface (0302) are properly delivered (0308) to the proper messagerecipient(s) (0311, 0321, 0329) with confirmation (0309) of messagedelivery, irrespective of the status of the messaging hardware interface(0307) at each of the message recipient (0311, 0321, 0329) locations.Communication protocols between the message routing/delivery process(0305) and the remote message hardware interfaces (0307) ensure thatmessages are delivered (0308) in a timely fashion, and if not properlyacknowledged (0309), then transferred to alternate messaging hardwareinterfaces (0307) associated with alternate message recipients (0321,0329).

This generalized system configuration anticipates that the messagerouting/delivery process (0305) may be distributed among severalcomputer systems (some not shown in the diagram), with some scenariosutilizing the message terminal interface system (0303) as a “thinclient” for remote server (0330) interface support.

Additionally, it should be noted that the messaging hardware interface(0307) may be presented individually to a wide variety of messagerecipients (0311, 0321, 0329) and may be configured in a wide variety ofhardware systems, including those that support mobile applications.

Method Overview (0400)

The above exemplary messaging system may implement a messagerouting/delivery method as generally illustrated in FIG. 4 (0400),wherein the messaging method comprises the following steps:

-   -   (1) A message and its target destination recipient are entered        via a user interface by a message originator (0401);    -   (2) The message is transmitted to its current target recipient        (0402);    -   (3) If the message delivery is unsuccessful, control passes to        step (5) (0403);    -   (4) Successful message delivery is typically not reported to the        message originator, and control passes to step (1) (0404);    -   (5) Message delivery failure via auto-forward is reported to the        message originator (0405);    -   (6) An alternate delivery address and message recipient is        selected based on message definition routing (0406);    -   (7) If an alternate message delivery address is available,        control is passed to step (2) (0407);    -   (8) Otherwise, message delivery system failure is reported to        the message originator process for optional review by the        message originator (0408); and    -   (9) The message routing/delivery method is terminated (0409).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention. While there are manymethodologies to ensure proper delivery of messages from the messageoriginator to the message recipient, the above methodology is only oneof several preferred methods.

Top Level System Embodiment (0500)

The general system architecture of the present invention is illustratedin FIG. 5 (0500). The system generally comprises a message database(0510) serviced by a file server (0511) operating under control ofmessage hosting software (0512) having computer readable softwareresiding on a non-transitory computer readable medium (0513). The fileserver (0511) communicates (0501) with a messaging source interface(0521) under control of a messaging source client process application(0522) that may contain software residing on a non-transitory computerreadable medium (0523). The messaging source interface (0521) collectsmessages from a user (0524) and transmits this information (0520) to themessage host (0512) to the file server (0511) and into the messagedatabase (0510).

It should be noted that the message host (0512) and file server (0511)may represent a geographically and spatially diverse set of hardware andsoftware, such that the system/method described herein could beimplemented on a worldwide basis if necessary. This configuration wouldprovide the capability of periodically polling each and every targetsystem interface serviced by the system to interrogate its currentavailability/status. In this manner target system interfaces that arenot available can be eliminated from consideration for messagetransfers.

The message information (0520) may be tagged with a variety ofinformation regarding the severity and/or urgency of the message alongwith other information dictated by the user (0524). This information(0520) is then processed through a hierarchical message transmissionthread that determines which target user should receive the messageinformation (0520) and in what order they should receive theinformation.

The general information flow from the message database (0510) traversesthrough the hierarchical message transmission thread by first attemptingto transmit the message information to the head of the thread, targetinga first message target system (0531) having target client softwareprocesses (0532) with the software residing on a non-transitory computerreadable medium (0533). The message (0530) is presented to a firsttarget user (0532), utilizing audio and/or visual methodologies withinthe target interface system (0531).

If the first target user (0534) fails to respond to the message (0530)within a predetermined time interval monitored by a message host timer(0514), the message host process (0532) notes this fact, notifies thesource user (0524) via the source system interface (0521) underdirection of the messaging source client (0522).

Failure of the first target user (0534) to properly respond to themessage information (0530) causes the message (0530) to be retransmittedto the next user (0544) on the hierarchical message transmission threadvia a new message (0540) directed at the next target system interface(0541) under management of message targeting client processes (0542)that are directed by software residing on a non-transitory computerreadable medium (0543). Responses by the subsequent target systeminterface (0541) under management of message targeting client processes(0542) may be logged (0550) back to the preceding target systeminterface (0532) as well as logged in a message archive.

Should the secondary user (0544) fail to respond in a predetermined timespecified by the message host timer (0514), the hierarchical messagetransmission thread is further traversed to determine the next availabletarget system interface and associated target client software and targetuser. Thus, the process iterates throughout the hierarchical messagetransmission thread until some target user responds to the message. Thismessage response is entered by the recipient and forwarded back to themessage host and eventually the messaging source user (0524). A logmaintaining all activity in this regard is provided for archivalinspection and current review by the messaging source user (0524). Inevery instance, the failure of the target user to respond within apredetermined time is relayed via message to the messaging source user(0524).

The system as described may also incorporate a “pass thru” mechanismwherein the message target client (0532, 0542) permits the target user(0534, 0544) to comment on the message and pass it along for furtherinspection by other users in circumstances where the message is notedbut cannot be acted on by a given user. This “pass thru” functionalitymay also be augmented with a “conditional branching” functionalitywherein the message is copied to a new thread of target users butallowed to also flow along its current target message thread based onactivity of the recipient and conditional branching requirements definedby the message sourcing process. This scenario might be appropriate insituations where the message must be acted on by a particular operatinggroup within the company, but the originator of the message realizesthat a completely different operating group may also need to be notifiedof the message contents and act appropriately within their individualoperating group.

General System Information Flow

The present invention can be generally described with respect toinformation flow among the components as follows, with the messagingsystem comprising:

-   -   (a) message database (0510);    -   (b) message file server (0511);    -   (c) message host process operating on the file server (0512);        and    -   (d) non-transitory computer readable medium incorporating        computer instructions comprising the message host process        (0513);    -   (e) source message system interface (0521);    -   (f) source messaging client process (0522);    -   (g) non-transitory computer readable medium incorporating        computer instructions comprising the source messaging client        process (0523);    -   (h) target messaging system interface (0531);    -   (i) target messaging client process (0532); and    -   (j) non-transitory computer readable medium incorporating        computer instructions comprising the target messaging client        process (0533);    -   wherein    -   the source messaging client process (0522) receives messages and        message severity/urgency classifications from a user (0524) via        the source messaging system (0521);    -   the source messaging system (0521) transmits the messages and        message severity/urgency classifications to the message host        process (0512) for storage on the message database (0510) via        the message file server (0511);    -   the message host process (0512) transmits the message and the        message severity/urgency classification to the target system        interface (0531) via a communications medium (0501) for display        by the target system interface (0531) under control of the        target message process (0532);    -   the target message process (0532) responds to the message host        process (0512) if the message is examined on the target system        interface (0531) by a target user (0534);    -   the message host process (0512) waits a predetermined amount of        time (0514) for the response to the message by the target user        (0534) and if the predetermined time (0514) is exceeded, the        message is retransmitted to another target system interface        (0541) for inspection by another target user (0544); and    -   the message host process (0512) reports to the source message        process (0522) the status of attempts to deliver the message to        each of the target systems (0531, 0541).

One skilled in the art will recognize that the integration of the systemdiagram in FIG. 5 (0500) along with the flowchart in FIG. 6 (0600)yields this exemplary data flow description.

Top Level Method Embodiment (0600)

Given the foregoing teachings of the present invention systemcomponents, the generalized method architecture for the presentinvention can be viewed as described in FIG. 6 (0600). In this context,the messaging method incorporates a system comprising the followingelements:

-   -   (a) message database (0510);    -   (b) message file server (0511);    -   (c) message host process operating on the file server (0512);        and    -   (d) non-transitory computer readable medium incorporating        computer instructions comprising the message host process        (0513);    -   (e) source message system interface (0521);    -   (f) source messaging client process (0522);    -   (g) non-transitory computer readable medium incorporating        computer instructions comprising the source messaging client        process (0523);    -   (h) target messaging system interface (0531);    -   (i) target messaging client process (0532); and    -   (j) non-transitory computer readable medium incorporating        computer instructions comprising the target messaging client        process (0533);    -   wherein    -   the source messaging client process (0522) receives messages and        message severity/urgency classifications from a user (0524) via        the source messaging system (0521);    -   the source messaging system (0521) transmits the messages and        message severity/urgency classifications to the message host        process (0512) for storage on the message database (0510) via        the message file server (0511);    -   the message host process (0512) transmits the message and the        message severity/urgency classification to the target system        interface (0531) via a communications medium (0501) for display        by the target system interface (0531) under control of the        target message process (0532);    -   the target message process (0532) responds to the message host        process (0512) if the message is examined on the target system        interface (0531) by a target user (0534);    -   the message host process (0512) waits a predetermined amount of        time (0514) for the response to the message by the target user        (0534) and if the predetermined time (0514) is exceeded, the        message is retransmitted to another target system interface        (0541) for inspection by another target user (0544) irrespective        of any reply by the first target user; and    -   the message host process (0512) reports to the source message        process (0522) the status of attempts to deliver the message to        each of the target systems (0531, 0541);

with the method comprising the steps of:

-   -   (1) entering a message from the messaging source interface        (0601);    -   (2) selecting a message severity/urgency classification from the        messaging source interface (0602);    -   (3) transmitting the message severity/urgency classification to        the message host and storing the message on the message database        via the file server (0603);    -   (4) traversing a hierarchical target message thread to determine        the targets for the message (0604);    -   (5) selecting the next message target within the hierarchical        message thread (0605);    -   (6) determining if the hierarchical message thread is exhausted,        and if so, proceeding to step (10) (0606);    -   (7) transmitting the message to the currently selected target        system interface within the hierarchical message thread (0607);    -   (8) determining if the message has been read by the currently        selected target system interface within the hierarchical message        thread, and if so, proceeding to step (11) (0608);    -   (9) determining if a target response timer has expired, and if        not, proceeding to the step (8) (0609);    -   (10) reporting to the source messaging interface that message        reception has failed and proceeding to the step (5) (0610);    -   (11) reporting status of message delivery to previous steps in        the hierarchical thread (0611);    -   (12) reporting to the source messaging interface that the        message has been received and returning any optional user        comment (0612); and    -   (13) optionally entering comments on the message and/or passing        thru the message to the current or another hierarchical message        thread (0613).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

Exemplary System Network Layout (0700, 0800)

While many network communication topologies are possible to implementthe present invention system/method, one preferred system network layoutis described in FIG. 7 (0700) and FIG. 8 (0800), with the followingtypical elements of construction:

-   -   Client (0711)—This represents any client such as a large company        or organization.    -   Government (0712)—This represents a government or not-for-profit        organization.    -   Laptop (0713)—This represents any wireless client using a laptop        to connect to the network.    -   Smartphone (0714)—This represents any smart device such as a        smartphone or mobile device.    -   Tablet Computer (0715)—This represents any mobile computing        device such as a tablet computer.    -   The Certificate Server (0721), Proxy Server (0722), and Web        Server (0723) reside behind firewall 1 (0720) and provide the        primary level of authentication and validation of licenses.    -   Certificate Server (0721)—Certificate servers validate, or        certify, keys as part of a Public key infrastructure. Keys are        strings of text generated from a series of encryption algorithms        that allow secure communications for a group of users. Keys are        created that used for validation. The process creates a way        ensure communications between clients and servers and be        reasonably sure that others are not eavesdropping or assuming a        false identity.    -   Proxy Server (0722)—The proxy server acts as an intermediary for        requests from clients seeking resources from our databases. A        client connects to the proxy server, requesting some service,        such as a file, connection, web page, or other resource        available from a different server. The proxy server evaluates        the request according to its filtering rules. If the request is        validated by the filter, the proxy provides the resource by        connecting to the relevant server and requesting the service on        behalf of the client. This would be a reverse proxy (or        surrogate) that appears to clients to be an ordinary server.        Requests are forwarded to one or more origin servers which        handle the request. The response is returned as if it came        directly from the proxy server providing another layer of        protection to the back end (internal) servers which reside        behind the secondary firewall.    -   Web Server (0723)—The Web server refers to either the hardware        (the computer) or the software (the computer application) that        helps to deliver content that can be accessed through the        Internet. It serves as an interface between the servers behind        the primary firewall and the backend servers (i.e., the proxy        server and the database server).    -   The License Server (0731), Authentication Server (0732), and        Database Server (0733) reside behind firewall 2 (0730) and        provide the secondary level of authentication and validation of        licenses.    -   License Server (0731)—This is the key server for software        licensing that refers to a centralized computer software system        which provides tokens, or keys, to client computers in order to        enable licensed software to run on them. This server determines        and controls the number of copies of a software program        permitted to be used based on the license entitlements that our        client(s) have purchased. This server provides licensing        services to an enterprise computing environment. In essence it        manages software licensing based on specific software product        offerings.    -   Authentication Server (0732)—These servers provide        authentication services to users or other systems via        networking. Remotely placed users and other servers authenticate        to such a server, and receive cryptographic tickets. These        tickets are then exchanged with one another to verify identity.        Authentication is used as the basis for authorization        (determining whether a privilege will be granted to a particular        user or process), privacy (keeping information from becoming        known to non-participants), and non-repudiation (not being able        to deny having done something that was authorized to be done        based on the authentication).    -   Database Server (0733)—The database server is a computer system        and associated software that provides database services to other        computer programs or computers, as defined by the client-server        model. Database management systems provide database server        functionality, and function on a client-server model for        database access. Such a server is accessed through the “back        end” which runs on the server and handles tasks such as data        analysis and storage. In this master-slave model, the database        master servers are central and primary locations of data while        database slave servers are synchronized backups of the master        acting as proxies.    -   Client Database A (0734)—This is a dedicated database for one        client (Client A).    -   Client Database B (0735)—This is a dedicated database for one        client (Client B).

One skilled in the art will recognize that many other networkcommunication topologies are possible when implementing the presentinvention without departing from the spirit of the invention.

Message Transport Methodologies

The present invention anticipates a wide variety of messagetransportation methodologies, with several of the preferredmethodologies illustrated generally in FIG. 9 (0900), FIG. 10 (1000),FIG. 11 (1100) and described below.

Parallel Message Transmission (0900)

As generally illustrated in FIG. 9 (0900), the present inventionanticipates the use of parallel message transmission in the delivery ofmessages. In this case a message originator (0901) interacts with amessage entry interface (0902) under control of a communication process(0903) to generate message text (0904) that is delivered using aparallel transport mechanism (0905) simultaneously to a number of clientpresentation interfaces (0906, 0907, 0908).

The message recipients associated with these client presentationinterfaces (0906, 0907, 0908) are generally kept in a recipient listdatabase under either individual identifications and/or distributionlists. Key to this transport mechanism is that the parallel messagetransportation algorithm (0905) “broadcasts” the message (0904) to allof the recipient client presentation interfaces (0906, 0907, 0908)without regard to priority for any given message recipient. While thecommunication with the client presentation interfaces (0906, 0907, 0908)may be bi-directional, the parallel transport mechanism (0905) considersthe group of target recipients to be a single recipient for the purposesof scheduling the message (0904) transport.

Cascade (Serial) Message Transmission (1000)

As generally illustrated in FIG. 10 (1000), the present inventionanticipates the use of cascade (serial) message transmission in thedelivery of messages. In this case a message originator (1001) interactswith a message entry interface (1002) under control of a communicationprocess (1003) to generate message text (1004) that is delivered using acascade transport mechanism (1005) sequentially to a number of clientpresentation interfaces (1006, 1007, 1008) using a particular order ofdelivery.

This transport mechanism differs from parallel transport in that underparallel message transmission, all of the target client presentationinterfaces (0906, 0907, 0908) receive the transmitted message, whereasin the case of cascade transmission only the first responding clientpresentation interface (1006, 1007, 1008) who accepts the message willreceive the message, with the remaining client presentation interfaces(1006, 1007, 1008) not necessarily receiving the message. Should a givenclient presentation interfaces (1006, 1007, 1008) timeout onacknowledgment and/or reply to a given message (1004), the remainingclient presentation interfaces (1006, 1007, 1008) in the serial cascadechain will be given the opportunity to accept, acknowledge, and respondto the message (1004). This particular method of message transport isespecially applicable in situations where a rigorous chain-of-command isimposed on responding to messages, such as in the case of emergencymanagement personnel and the like.

Mixed Mode Message Transmission (1100, 1200)

As generally illustrated in FIG. 11 (1100) and FIG. 12 (1200), thepresent invention anticipates the use of mixed mode parallel/cascade andcascade/parallel message transmission methodologies in the delivery ofmessages. From these exemplary diagrams it can be seen that thefollowing types of message transport are anticipated by the presentinvention:

-   -   Parallel message transport (FIG. 9 (0900));    -   Cascade message transport (FIG. 10 (1000));    -   Parallel/cascade message transport (FIG. 11 (1100));    -   Cascade/parallel message transport (FIG. 12 (1200));    -   Parallel/parallel message transport (equivalent to a terminal        cascade branch that has a parallel transport mode branch);    -   Cascade/cascade message transport (equivalent to a terminal        parallel branch that has a cascade transport mode branch).

One skilled in the art will recognize that these individual messagetransport modes and their variations can be combined in a wide varietyof ways to cover an enterprise message distribution network in ways thatare optimal to the both the reception and proper processing of messagesthat are of a property and/or life-critical nature.

Anticipatory Message Queuing (AMQ)

Conventional Message Delivery Overview (1300)

Under normal circumstances, the present invention processes messages bysequentially transmitting the message to addresses contained in ahierarchical target message address list. After each transmission, apredefined amount of time is allocated to determine if a response to themessage has been received by the host message processor. If no responsemessage is received (or if the response indicates that the messageshould be passed thru or passed around) the next address in thehierarchical target message address list is selected as the target forthe message. This process continues until a successful response/actionmessage is received from a targeted system interface.

This scenario can be seen by illustration in FIG. 13 (1300), wherein thecascade message transport (1305) first transmits the message to a firstclient presentation interface (1306) after which it is subsequentlyrouted to a second client presentation interface (1308) and subsequentlya third client presentation interface (1308) (assuming the first twoclient presentation interfaces (1306, 1307) auto-forward the message).There always exists a delay between the auto-forward timeout and thedelivery reception of the message to the next downstream cascade messagereceptor. This additional delay is in addition to the auto-forward timeand in some circumstances can be significant.

Anticipatory Message Queuing Methodology (1400)

The present invention also teaches several augmented versions of thismessage delivery system collectively termed “anticipatory messagequeuing.” As generally illustrated in FIG. 14 (1400), under thismodification, each time a message is sent to a target system interface(1406), the same message is sent to the next target system interface(1407) addressed by the hierarchical target message address list. Thisanticipatory message is tagged as “preliminary” and not immediatelyprocessed by the subsequent target system interface (1407). Should thecurrent target system interface (1406) fail to respond within apredetermined time interval, the message host process can merely send anactivation message to the subsequent target system interface (1407) totrigger processing of the previously received message. Thus, thismessage delivery architecture distinguishes between a message being“received” and being “active” on the current target system interface.

Alternative Anticipatory Message Queuing Methodology (1500)

An alternative to the AMQ methodology of FIG. 14 (1400) is illustratedin FIG. 15 (1500), wherein the message is simultaneously transmitted toALL target system interfaces (1506, 1507, 1508) and then triggered as“active” by the communications process (1503) if the previous systeminterface timed out and auto-forwarding is mandated. The advantage ofthis approach is the fact that intermediate next-target communicationscan occur for ALL potential system targets without the need for waitingfor an auto-forward condition to occur. Given that it might take asubstantial time for the initial target communications to take place,this reduction in overhead can be significant.

Autonomous Anticipatory Message Queuing Methodology (1600)

An improved alternative to the AMQ methodology of FIG. 15 (1500) isillustrated in FIG. 16 (1600), wherein the message is simultaneouslytransmitted to ALL target system interfaces (1606, 1607, 1608) alongwith timing information to determine when the previous system interfacewill have timed out. These two pieces of information permit the messageto be flagged as “pending” on each target interface and then triggeredas “active” locally if not stopped by the communications process (1603)or a communication from an upstream target system interface.

The advantage of this approach is that it anticipates a catastrophicfailure of the communications process (1603) such that a broadcast tothe entire network of possible target system interfaces will stillproceed as usual should one of the target recipients be unavailable orif there is a failure of any target system interface hardware. In thisfashion, the system integrates a level of “distributed failover” toallow major system components to fail while still providing robustmessage delivery capabilities.

Anticipator Message Queuing Advantages

This technique has the following advantages:

-   -   The message processing latency in the overall system is        decreased, as the subsequent target system interface can perform        all preprocessing on the message during the delay time        associated with the timer from the previous target system        interface. This can be useful in situations where decryption        time on the message is significant.    -   During the time delay period associated with the current target        system interface, the host message process can determine if the        subsequent target system interface is even available. If it is        not, then there is no time wasted in polling this target system        interface for a user response, and the host message process can        proceed to the next address in the hierarchical target message        address list.    -   Users associated with the subsequent target system interface can        be put on notice that they may be requested to act on a message        shortly and that this message is currently pending based on a        recipient farther up the message hierarchy list. In time        critical applications, this forewarning of an impending message        requiring immediate action could be critical in providing a        timely response to the message contents.

One skilled in the art will recognize base on the above teaching thatthe present invention could utilize a multi-stage anticipatory queuingtechnique where multiple target system interfaces below the currenthierarchy level are simultaneously notified of a pending message and puton alert that pending results further up the chain they will be requiredto act on the message in a timely manner. This would be very useful insituations where lower level subordinates within a management groupwould be expected to activate and deal with a time critical safety issueafter an upper level manager has been informed of the situation andgiven the chance to comment on a proposed action plan.

Message Routing by Decision Matrix

Calendar-Based Routing

The present invention anticipates that the timeouts associated withmessage retransmission to alternate target system interface(s) may bebased in part on specific calendar information, such as time-of-day,day-of-week, holiday and vacation schedules and the like. However, somepreferred embodiments of the present invention significantly extend thiscapability to include dynamic decision routing as detailed below.

System Overview (1700)

As mentioned previously, some preferred embodiments of the presentinvention anticipates the use of calendars and other timing informationto provide dynamic message routing in some circumstances. One suchsystem implementation of this concept is illustrated in FIG. 17 (1700),wherein the message originator (1701) interacts with the message entryinterface (1702) and communications process (1703) as normal to generatea text message (1704), but message delivery routing is determined by adecision matrix (1705) that may have a variety of inputs, including butnot limited to calendars (1706), external real-time events (1707), PLCinputs (1708), etc.

These decision inputs may be referenced by a user interface (1709)incorporating a Boolean operator routing selection syntax to selectwhich routing targets are associated with a given condition relating allof the external inputs to the decision matrix (1705). The decisionmatrix (1705) will then determine the proper routing destination andtype for a given message and state of external conditions in order toproperly adjust message routing for the particular environment in whichthe message is being delivered. Once the message routing decision hasbeen made, a message delivery engine (1710) associated with thecommunications process (1703) to actually deliver the message to themessage recipient (s) (1711).

This dynamically adjustable event-driven message routing capabilitypermits a wide range of adaptability to be incorporated into themessaging system that drastically increases the capability to adjust fordaily, weekly, monthly, seasonal, and other cyclic events that are notcapable of being accounted for with strict message delivery protocols.

Method Overview (1800)

The method associated with the above detailed decision matrix routingsystem includes the following steps as generally illustrated in FIG. 18(1800):

-   -   (1) entering a message from the messaging source interface        (1801);    -   (2) selecting a message severity/urgency classification from the        messaging source interface (1802);    -   (3) process inputs to the routing decision matrix (Boolean        operator routing selection interface inputs (1821) applied to        external decision matrix inputs (1822)) to determine the dynamic        message routing (1803);    -   (4) transmitting the message severity/urgency classification to        the message host and storing the message on the message database        via the file server (1804);

(5) traversing a hierarchical target message thread to determine thetargets for the message (1805);

-   -   (6) selecting the next message target within the hierarchical        message thread (1806);    -   (7) determining if the hierarchical message thread is exhausted,        and if so, proceeding to step (11) (1807);    -   (8) transmitting the message to the currently selected target        system interface within the hierarchical message thread (1808);    -   (9) determining if the message has been read by the currently        selected target system interface within the hierarchical message        thread, and if so, proceeding to step (12) (1809);    -   (10) determining if a target response timer has expired, and if        not, proceeding to the step (9) (1810);    -   (11) reporting to the source messaging interface that message        reception has failed and proceeding to the step (4) (1811);    -   (12) reporting status of message delivery to previous steps in        the hierarchical thread (1812);    -   (13) reporting to the source messaging interface that the        message has been received and returning any optional user        comment (1813); and    -   (14) optionally entering comments on the message and/or passing        thru the message to the current or another hierarchical message        thread (1814).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

Exemplary Boolean Operator Routing Selection Syntax (1900)

A simple example of how the Boolean operator routing selection syntaxmay be implemented is generally illustrated in FIG. 19 (1900). Thissyntax matches that of the simple message routing diagram illustrated inFIG. 23 (2300), with the exception that various Boolean operators andconditions have been incorporated ([not SUNDAY], [not HOLIDAYS],[WEEKDAYS]) to indicate that calendar-specific limitations have beenplaced on the transmission of messages to the indicated individuals.

One skilled in the art will recognize that the Boolean syntax depictedin FIG. 19 (1900) can be easily implemented as a GUI to permit CAs toeasily create highly complex decision trees associated with messagedelivery. As stated previously, the ability to obtain DYNAMIC inputs andmake message delivery decisions based on these inputs is also a usefulfeature of this technique. For example, conditions such as [BOILER DOWN]or [AMBULANCE AVAILABLE] and the like provide some input into the natureof how dynamic this message transport decision matrix can become.

Message Encryption

While transmission of the messages between the message host (0512)process and the individual message clients (0522, 0532, 0542) may occurin a wide variety of ways, the present invention anticipates that manypreferred exemplary embodiments may utilize encryption of the messagesto ensure message security both within the context of the individualcomputer servers (0511, 0521, 0531, 0541), but also during transmissionover the communications medium (0501).

Message Logging

The present invention anticipates that as part of the messagetransmission facility present in each of the source (0522) and target(0532, 0542) processes there will exist a logging function to record theuser responses to message inquiries and also copy the message responseup the message hierarchy delivery chain so that persons up the chain arefully notified of lower level subordinate responses to messageinquiries. Many preferred exemplary embodiments of the present inventionwill incorporate message logging to

-   -   (a) a message archive,    -   (b) as a forwarding message to the next target system        interfaces, and    -   (c) to the preceding target system interface.

Exemplary Menu Item Message Level Classifications

While the present invention anticipates a wide variety ofclassifications may be associated with a given message, the followinglist may be suitable for many preferred exemplary embodiments of thepresent invention that incorporate a menu selection of messageclassification:

-   -   LIFE CRITICAL/MISSION CRITICAL    -   CRITICAL—Non-Immediate life threatening but with a significant        life/monetary imperative.    -   URGENT—but with a Moderate life/Monetary imperative.    -   CORRECTIVE ACTION/AUDIT.    -   CONTINUOUS IMPROVEMENT/SUGGESTION.    -   INFORMATION TRANSFER such as Capital Improvement Project        release, or Project status reports, etc.    -   ANONYMOUS REPORTING. This option provides the opportunity to        report any information to a specified client representative        without fear of reprisal. The system/method described herein        will have knowledge of the reporting individual's identity, but        this identity will only be breached under stringent requirements        provided by the client.

One skilled in the art will recognize that these menus messageseverity/urgency classification levels are only exemplary and can becontracted or expanded within the scope of a particular implementationwithout loss of generality in the teachings of the present invention.

Exemplary Severity Level Classifications

While the present invention anticipates a wide variety of severity levelclassifications may be associated with a given message, the followinglist may be suitable for many preferred exemplary embodiments of thepresent invention:

-   -   SEVERE—Related to fire and/or personal injury.    -   SERIOUS—Related to critical communications.    -   MODERATE—Related to immediate communications.    -   MINOR—Related to informational communications.    -   ANONYMOUS—Related to anonymous communications with sender's        identification blocked from all recipients. This option provides        the opportunity to report any information to a specified client        representative without fear of reprisal. The system/method        described herein will have knowledge of the reporting        individual's identity, but this identity will only be breached        under stringent requirements provided by the client.

One skilled in the art will recognize that these classification levelsare only exemplary and can be contracted or expanded within the scope ofa particular implementation without loss of generality in the teachingsof the present invention.

Exemplary Urgency Level Classifications

While the present invention anticipates a wide variety of urgency levelclassifications may be associated with a given message, the followinglist may be suitable for many preferred exemplary embodiments of thepresent invention:

-   -   IMMEDIATE—An event or action is occurring requiring immediate        management attention.    -   URGENT—An event or action requiring urgent management attention.    -   NEED SOON—An event or action requiring management attention.    -   INFORMATIONAL ONLY—An event or action has occurred—informational        only.    -   ANONYMOUS—Related to anonymous communications with sender's        identification blocked from all recipients.

One skilled in the art will recognize that these classification levelsare only exemplary and can be contracted or expanded within the scope ofa particular implementation without loss of generality in the teachingsof the present invention.

Exemplary Anonymous Message Processing

The present invention anticipates that a message may be submittedanonymously. In these circumstances the identity of the sender must behidden from the recipients, but in some critical situations thisanonymity must be breached. Thus, anonymous messages are handled in thefollowing manner:

-   -   The sender's identification blocked from all recipients unless a        most senior level manager with specific authority uses a “single        use management key” that will unlock the sender's identity.    -   This key will reside with the message hosting system and must be        requested in writing, from a known source, sent to a known        address.    -   There will be a substantial fee associated with each key, both        for its creation and storage, to deter use of these keys in        other than critical situations.

One skilled in the art will recognize that this use of anonymousreporting can be contracted or expanded within the scope of a particularimplementation without loss of generality in the teachings of thepresent invention.

Preferred Exemplary Embodiment Characteristics

Many preferred exemplary embodiments of the present invention willexhibit the following characteristics and features:

-   -   At the expiration of a target user response timer the system        will auto-forward the message.    -   The messaging source client process will only permit pre-defined        specific users fields to be manipulated, and only to a pre-set        point. Once a message has left a target system interface, only        those portions which may be open to the next stop recipients'        may be manipulated.    -   In general, the message may not be (a) printed, copied, screen        shot, or stored in any other form for reprinting; (b)        re-directed, or caused to have its routing changed once the        message is sent, by the originator; (c) de-encrypted buy anyone        other than the recipients', unless a master executive key is        used, and an auto record of that action placed in the logging        archive.    -   A strong (Internal File) encryption system is generally used for        message storage and transmission.    -   The encryption/un-encryption should optimally be both single        file and batch file capable.    -   All message system correspondence generated “may” be sent to        clients external to the messaging system, and therefore in this        specific event, the correspondence cannot be encrypted.    -   Each message once transmitted will be archived (including        bi-directional transmittals), providing a message paper trail.    -   Message archives should index messages by title/header and        content making retrieval possible.    -   Configuration of software on a computer system should ONLY be        completed by a designated person who has the proper software        encoded credentials. It should allow on-site as well as remote        program configuration.    -   The end user will generally need sufficient training in the use        of the software.    -   Delivery of system software components should be provided in a        standalone format over the Internet or within Client's internal        networks or within conventional smartphone/mobile device        telephone networks.

One skilled in the art will recognize that this list is not exhaustiveof the features of many preferred embodiments of the present invention.

System Administration by Certified Administrator (CA)

System Administration by Certified User (2000)

Optimal embodiments of the present invention anticipate that themessaging system will be managed by a Certified Administrator (CA) ormessaging system “super user” that is responsible for setting messagingpolicies and enforcing standards within the overall messaging systemframework. A typical system architecture employing this framework isgenerally illustrated in FIG. 20 (2000), wherein both the messageoriginator (2010) and Certified Administrator (2020) each have theircorresponding user interfaces (2019, 2029) into one or moresetup/message entry interfaces (2001) that are under control of theoverall communications process (2002) as discussed herein.

Key to this implementation is that the Certified Administrator (CA) canmanage user messaging accounts and set internal messaging policies tocontrol the overall behavior of the message delivery system, as well asauthorize levels of message delivery by a given user, etc. The CA (2020)also has the responsibility of accepting and implementing MessageDefinition Forms that describe various types of canned messages, theirdelivery protocols, and actions to be taken in the event of variousdisasters or other property/life threatening events.

Message Generation/Security Architecture Overview (2100)

The disclosed messaging system/method incorporates a high degree of bothreliability and security, and part of this architecture requires in manypreferred embodiments the use of a “Certified Administrator (CA)” toimplement details of the system functionality and regulate access to theinternals of the messaging system/method. The control structureimplementing this architecture is generally illustrated in FIG. 21(2100).

Referencing FIG. 21 (2100), the messaging system is driven by messageauthors (2101) that generate requests for messages on a messagedefinition form (2102) (which may be in the form of a paper form or anelectronic equivalent). These message definition forms (2102) describein detail the type of message to be transmitted, under whatcircumstances the message is to be transmitted, and the block ofsimultaneous recipients (parallel simultaneous transmission) and/orsingularly sequential recipients (serial step-by-step transmission).Note that this message distribution methodology may incorporate acombination of serial and/or parallel branch transmissions in thisdistribution methodology.

Once the message definition form (2102) has been completed, it isreviewed by a CA (2103) who then enters this message information into amessage definition process (2104) to define a message definitiondatabase (2105) describing the exact message characteristics and themessage distribution tree methodology. This message definition database(2105) will incorporate both a recipient list and alternate routinginformation (2106) to ensure that the message is properly acted on by anappropriate individual in the chain of command.

Once the message definition database (2105) has been properly modifiedby the message definition process (2104) under control of the CA (2103),this information can be used by the message communications process(2107) interacting with a message originator (2108) to ensure properdelivery of the message to appropriate message recipients in the chainof command.

By formalizing the structure of the message definition database (2105)with the use of message definition forms (2102) that are reviewed andauthorized by the CA (2103), both security and integrity of themessaging system are maintained.

Message Definition Form Example (2200, 2300)

An example of a Message Definition Form and associated cascade/parallelstop information dialogs is generally illustrated in FIG. 22 (2200).Here the new message definition form (2201) indicates a typicalinteraction with the message author in defining the messagecharacteristics and architecture of message delivery. Associated withthis message delivery architecture will be a variety of cascade (2211,2212) and/or parallel (2221, 2222) message stop definition dialogs thatwill define the specific techniques used to distribute the message amongthe various selected message recipients.

A typical example of a message delivery architecture is illustrated inFIG. 23 (2300), wherein a Severity+message (2301) is generated toindicate a FIRE AND MAN DOWN (2302). This message is broadcast (inparallel transmission mode) to 911 FIRE (2303), 911 RESCUE (2304),INTERNAL SECURITY (2305), HR PUBLIC RELATIONS (2306), and CONTINUINGEXCELLENCE ACCIDENT INVESTIGATION (2307). Within these groups, serialcascade message transmission is directed towards individual chains ofrecipients within the various organizations (CORPORATE DUTY OFFICER(2308), VP OPS (2309); HR PUBLIC RELATIONS ACTION TEAM (2310), VPFINANCE (2311); ACCIDENT INVESTIGATION TEAM (2312), VP SAFETY (2313)).In this manner the message is properly broadcast to both the BREADTH andDEPTH necessary to address the critical situation, without necessarilywaiting on any particular message recipient to act independently of theremaining message recipients.

While the message delivery architecture of FIG. 23 (2300) is typical ofwhat can be achieved with the present invention, it is not limitive, asany combination of parallel/cascade and cascade/parallel messagetransmission architectures are possible using the message deliverydefinitions defined by the message definition form.

Certified Administrator (CA) Login Interface (4100)

As generally illustrated in FIG. 41 (4100), the CA follows the samelogon procedure as a general messaging user.

Certified Administrator Client Secured Login (4200)

When authentication is validated and any appropriate licenses arevalidated the software will present the certified administrator loginscreen as generally illustrated in FIG. 42 (4200). In the space providedCertified Administrator (CA) enters password and authentication code.The following steps are then performed:

-   -   The messaging system software issues a “watch for warning code”        to determine if any abnormal system conditions are associated        with the login procedure.    -   If no warning code is found and authentication is valid software        is authorized to present certified administrator (CA) dashboard.    -   If no warning code is found and authentication is invalid        software is to present login screen.    -   CA will have two additional retries to login for a total of        three tries at which time the system will lock out any further        attempts to login and notify the CA that they need to contact        their CA to correct the problem.    -   If warning code entered notify per message definition form and        continue to allow unrestricted number of retries.

The CA takes action based on message definition form furnished, tocreate system messages for later use by message originators.

Certified Administrator Post Login Steady State (4300)

When authentication is validated for the CA, a system dialog menu asgenerally illustrated in FIG. 43 (4300) is presented to the CA, fromwhich he/she can select appropriate functions to define and testmessages and delivery threads.

Create System Message (4300)

The present system/method anticipate a variety of options for the CA tocreate system messages, including special considerations where themessage creation is interrupted while creating a system message. Inthese circumstances options are available as a drop down from the CreateSystem Message, Create User Message Tabs, and Modify Message Tab. Theseoptions include:

-   -   Back—unwind one menu level;    -   Cancel—cancel the operation;    -   Save—Retain a copy of the message definition form in system;    -   Edit—Open a copy of a saved message for editing.

The general outline for message creation by the CA is as follows:

-   -   From dashboard the CA selects the ‘Create Message’ tab and from        the drop down selects ‘Make Live’ and selects ‘Do not make        live’. Select the Do Not Make Live Button.    -   From the dashboard select the Tool Set Tab. From the drop down        select ‘Show Message ID’. CA enters Severity Number and Urgency        number into “Review Message ID for the Severity_(——————) and        Urgency_(——————). Doing this verifies that the message severity        number and urgency number is or is not currently in use. The CA        then reads the “Review Message ID Report”, on the dashboard.    -   From the dashboard the CA selects Create System Message—Do not        make live, and place a check mark in the box for YES for message        severity and urgency to be locked.    -   From the dashboard the CA selects the Lock Tab and from the drop        down pick LOCK tag severity, and enters severity number. Tag        Severity_(——————) LOCK, and then click “LOCK” to lock it.    -   From the dashboard the CA selects the Lock Tab and from the drop        down picks LOCK tag urgency, and enter urgency number. Tag        Urgency_(——————) LOCK, and then click “LOCK” to lock it.    -   The CA next selects Create Message Tab then Create System        Message Tab.    -   The system now presents the ‘Create Message Stop’ drop down to        either create a Cascade (serial) or Parallel (broadcast) Message        blocks. The decision on which block to create in what order is        given by the Message Definition Form.    -   If parallel messaging is desired, from the drop down box select        parallel message. For each parallel message enter primary        recipients and alternate recipients for that message stop from        the message definition form provided. Use the “another” key to        add additional parallel recipients for that message stop. When        this message stop is completed, proceed using information        provided on the message definition form the next message stop.        If all stops are completed proceed to test.    -   If cascade serial messaging is desired, the CA selects the box        indicating cascade message. Enter time to auto forward for that        message stop. Enter primary recipients and alternate recipients        for that message stop from the message definition form provided.        Use the “another” key to add additional cascade recipients for        that message stop. When this message stop is complete move to        next message stop using information provided on the message        definition form for the next message stop. If all completed        proceed to test.    -   If the Create System Message is a combination of both parallel        and cascade create the message stop-by-stop from the message        definition form using the parallel then the cascade instructions        above.    -   When all data entry is complete and verified, the CA selects        ‘Proceed to Test’.    -   The CA will then be presented with the Test Tab options and will        select either: Select Method 1 which runs internal test only; or        Select Method 2 which alerts recipients that a test message will        be sent.    -   The CA runs the selected test.    -   The CA reviews Test Results displayed and verifies that the test        message completed or failed. If test message failed, the CA        determines the failure and make corrections. Notate changes and        comments on the message definition form. Rerun test. If the test        passed notate on message definition form the date created and        time. File a copy of this new system message created in the file        in the CA Office and send a copy of the completed new system        message form back to the message author.    -   From dashboard the CA selects the ‘Create Message’ tab and from        the drop down select ‘Make Live’ and then selects ‘Make Live’.        The CA then selects the Make Live Button.    -   From the dashboard the CA selects Create System Message, Make        Live, and places a check mark in the box for yes for message        severity and urgency to be Unlocked.    -   From the dashboard the CA selects the Unlock Tab and from the        drop down pick Unlock tag severity, and enters severity number.        Tag Severity_(——————)Unlock, and then clicks “Unlock” to unlock        it.    -   From the dashboard the CA selects the Lock Tab and from the drop        down pick Unlock tag urgency, and enter urgency number. Tag        Urgency_(——————) Unlock, and then clicks “Unlock” to unlock it.    -   The CA opens each Severity and Urgency Tab; verifies that the        new Severity and Urgency Numbers are present in the Menus and        not grayed out.    -   If either of the above conditions are not present, or are        incorrect—then correct until they are.        Create User Message (4400)

As generally illustrated in FIG. 44 (4400), the CA may also create usermessages. The general flow for this procedure is as follows:

-   -   The Dashboard displays the Current Status of existing messages        in the left-hand window and allows for the creation of or a        reply to a message (providing that the auto-forward timer has        not expired).    -   To create the message, the CA selects the Create Message tab        then from the drop down select Create User Message from the        Dashboard, which will the present the CA with the following        system driven menus:    -   Severity (FIG. 45 (4500))—The CA will be presented with the        Severity Menu where the appropriate Severity for the message is        selected. Note: The back button can be used to return to the        previous menu. The cancel button can be used to cancel the        message.    -   Urgency (FIG. 46 (4600))—The CA will be presented with the        Urgency Menu where the appropriate Urgency for the message is        selected.    -   Once the Severity and Urgency are selected the CA will then        enter the text to Create User Message.    -   The system will now present the CA with the system driven menus,        reference to the system menus described above. Within this        context, the Originator enters their name, and enters the        message in the available box.    -   Once the message is complete, and has been reviewed, the CA        selects SEND. Note: in many preferred embodiments all messages        are limited to a maximum of 125 words for Originator and each        subsequent reply area.    -   The originator's encrypted message will be sent to designated        recipients and the message will appear in the Current Status        window to the left of the dashboard in its Severity steady state        color.    -   A copy of the message will be sent in parallel to the message        archive and to the designated recipient(s).    -   When multiple messages exist in the current status section, by        hovering the mouse over the message, a ‘snapshot’ of the message        in notation form showing the originator and message title will        appear. (Additional information is possible to be displayed and        is configurable by the client.)        CA New Message Arrival and Reply (4700)

As generally illustrated in FIG. Z7 (4700), the CA may accept andrespond to messages. Here the CA must be logged into the system toreceive and reply to messages. Upon receipt of a new message the entiredashboard will flash in the alternating color of the severity of themessage color and a background color as well as make an alert sound uponarrival.

The dashboard may continue to flash in the alternating color of themessage severity color and background color and continue to play thealert tones until the message receipt has been acknowledged by clickingon the dashboard.

After clicking the dashboard the new incoming message will appear in theCurrent Status column at the top position and will flash in thealternating color of the severity color and background color of themessage at a nominal rate of two times per second, and will continue todo so until the auto forward timer has reached zero. If the CA takes noaction the message will be auto forwarded to the next message stoprecipient and the message will now stop flashing and be in thesteady-state color of the Severity for that message. The CA will nolonger have the ability to reply to message.

If the CA wishes to examine any message located under the current statussection they only need to hover the mouse over the message and anabbreviated amount of information will be displayed including the timeremaining till auto forward.

From the CA dashboard select the Modify Message Tab and from the dropdown select Reply to Message tab and then click the message you wish toreply to in the Current Status section of the dashboard.

Certified Administrator Reply to Message

The CA may read the Originator Message and any and all replies prior toa given message stop in the area ‘Originator Message Here’ then write areply in the “Enter Reply Here’ section. When finished and satisfiedwith the response the send button is selected by the CA.

Confirmation that the message was sent occurs when the message appearsin the current status section and is its steady state color of theSeverity of that message.

CA Message History (4800)

As generally illustrated in FIG. 48 (4800), the CA may obtain historicalinformation on messages by selecting the appropriate dialog box entry onthe dashboard.

CA Reading a Message Update

When a message reply is received the message will appear in the CurrentStatus column and will flash at a rate of one time per second in thealternating color of the severity and background color for the severityfor that message. This is a visual indication that a message reply hasbeen received and is ready for viewing by the user. The message willcontinue to flash until the user selects the message or until thatmessage has reached its final stop.

If the CA wishes to examine any message located under the current statussection he only needs to hover the mouse over the message and anabbreviated amount of information will be displayed including the timeremaining till auto forward.

After the message has reached its final destination/is complete, it willbecome viewable under the History Tab for a nominal time of fivebusiness days. It will then be removed and optimally archived on amessage archival storage system.

Certified Administrator Read Message

The CA can select messages in the Current Status window by clicking onthe check box to the left of the message subject. The dashboard willchange to that of FIG. 48 (4800). The area marked ‘Original MessageHere’ will display the entire message including the originator and eachmessage stop(s) that entered a reply and was forwarded to the nextmessage stop.

From the CA dashboard under the Current Status Section and click themessage you wish to read. When the CA is finished reading the selectedmessage they can close the message dialog box that displays the selectedmessage, by selecting the ‘Finished Reading’ Button. The dashboard willnow revert back to the steady-state and the message will return to thesteady-state color for that message severity and remain in the CurrentStatus section of the dashboard.

When multiple messages exist in the current status section, by hoveringthe mouse over the message, a ‘snapshot’ of the message in notation formshowing the originator and message title will appear. Additionalinformation is possible to be displayed and is configurable by the CAclient.

CA Administration of User Information (4900, 5000, 5100, 5200)

The CA interface may in many preferred embodiments utilize a variety ofdialog box configurations as generally illustrated in FIG. 49 (4900),FIG. 50 (5000), FIG. 51 (5100), and FIG. 52 (5200) to define thecharacteristics of individual users and also information regardingpotential message recipients.

User Login/Message Interface Dialog Sequence (2400)

Overview

As generally illustrated in FIG. 24 (2400), the process flow for themessage originator method can be generally described in terms of aflowchart comprising the following steps:

-   -   (1) A login dialog process is executed to validate the user        login credentials (2401);    -   (2) If the login process is unsuccessful, then the message        originator process terminates and control is passed to step (10)        with the system locked to prevent further login access attempts        (2402);    -   (3) A case branch is executed based on input from a main dialog        menu screen (as generally illustrated by FIG. 54 (5400)),        selecting one of a number of message management functions        (2403);    -   (4) If the menu selection is message severity, a message        severity selection dialog (as generally illustrated by FIG. 55        (5500) and FIG. 56 (5600)) is presented in which the message        originator selects from a fixed list of available message        severities (2404);    -   (5) If the menu selection is message urgency, a message urgency        selection dialog (as generally illustrated by FIG. 57 (5700) and        FIG. 58 (5800)) is presented in which the message originator        selects from a fixed list of available message urgencies (2405);    -   (6) If the menu selection is Log Off/Sign Out, control returns        to step (1) (2406);    -   (7) Upon completion of steps (4) and/or (5) the message        originator is prompted via dialogs either to enter (FIG. 59        (5900)) or modify (FIG. 60 (6000)) message text for transmission        (2407);    -   (8) If the message originator has not selected SEND for message        transmission, control passes to step (7), or alternatively if        the message transmission is abandoned/cancelled, control passes        to step (3) (2408);    -   (9) Once the message originator has requested that the message        be sent, the message is sentfor transport to the message        recipient (2409); and    -   (10) The message originator method terminates processing and        returns to step (3) (2410).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

Preferred Embodiment Details

While the above description provides general information regardingimplementation, some preferred embodiments will incorporate thefollowing implementation steps:

-   -   User inputs name and password at the login screen.    -   Information is sent to the Certificate Server where it is        validated.    -   The Certificate Server then processes the request and verifies        whether the requestor is qualified to receive a certificate.    -   If validated, a private key is created and issued to the        requestor.    -   If both conditions are found to be valid the user is then logged        into the messaging system. Note: All certificate transactions        are stored in the certificate database for the audit trail.    -   Once the certificate process is completed, the server will apply        a policy which tells the system what to do with the request.        This validates the access level that the requestor is presented        with after login.    -   If the request is rejected, the user will be given two (2)        additional attempts to input their username and password.    -   After three unsuccessful attempts, the requestor will be        notified that their request has been denied and present the        requestor with information on how to contact the certified        administrator for assistance and the requestor will be locked        out of the system.        License Validation Server

When a user logs into the system, the License Server will validate whichservices the user has available for use (This is applied through a grouppolicy defined at the time of installation, based on the individualuser's job duties. (The License Server also holds the license log filesof the clients' product and feature use.) The License Server is thesecond validation step before access to the message system is granted.

If the license validation for the username and password is rejected, asan example; the license has expired, the user will be locked out of thesystem until the Certified Administrator rectifies the trouble. Once thelevel of access is validated, the user will be granted access to themessaging system.

Create Message (5400)

The Dashboard displays the Current Status of existing messages in theleft-hand window and allows for the creation and/or reply to a message(providing that the auto-forward timer has not expired). To create themessage, select the Create Message tab from the Menu Dashboard, whichwill provide the present user with a variety of system driven menus,some exemplary embodiments of which are described below.

Severity (5500, 5600)

The user may be presented with a Severity Menu where the appropriateSeverity for the message is selected. Note: The BACK button can be usedto return to the previous menu. The CANCEL button can be used to cancelthe message.

Urgency (5700,5800)

The user may be presented with an Urgency Menu where the appropriateUrgency for the message is selected.

Message Creation Details (5500, 5600, 5700, 5800, 5900)

Once the Severity and Urgency are selected, the user may then create themessage. The system may present the user with the following systemdriven menus, reference the previously described menu Dashboard. Thegeneral information flow of this menu Dashboard is as follows:

-   -   Originator enters their Name.    -   The text message is entered in the available box.    -   Once the message is complete, and has been reviewed, SEND is        selected to transmit the message.

In many preferred embodiments the messages are limited to a maximum of125 words for Originator and each subsequent reply area. Theoriginator's encrypted message is then sent to designated recipients andthe message will appear in the Current Status window to the left of thedashboard and may be optionally highlighted in its severity state color.

When multiple messages exist in the current status section, by hoveringthe mouse over the message, a ‘snapshot’ of the message in notation formshowing the originator and message title may optionally appear.Additional information is potentially available to be displayed and isconfigurable by the client.

Message Originator/Recipient Login Validation Process (2500)

While the login validation process (2401) generally illustrated in FIG.24 (2400) may be implemented in many ways, one preferred exemplaryembodiment is generally illustrated in FIG. 25 (2500), and comprises thefollowing method steps:

-   -   (1) A login dialog (as generally illustrated by FIG. 53 (5300))        is presented to the user for data entry (2501);    -   (2) The message originator/recipient is prompted to enter a        username and password (2502);    -   (3) If the entered username and associated password are valid,        control is passed to step (8) (2503);    -   (4) If there are less than three failed login attempts, control        is passed to step (1) (2504);    -   (5) Further login attempts are blocked (2505);    -   (6) Notification is presented to the Certified Administrator        (CA) to indicate an attempted security breach (2506);    -   (7) An unsuccessful return completion status is indicated and        control is returned to the calling process (2407); and    -   (8) A successful return completion status is indicated and        control is returned to the calling process (2508).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

Message Transmission Protocol (2600)

Overview

A generalized overview of the message transmission protocol andassociated routing methodology is generally illustrated in the flowchartof FIG. 26 (2600) and will now be discussed in detail.

General Requirements

While many methodologies may be associated with the message transmissionprotocol, several are anticipated as preferred. Generally speaking, aspart of the message definition development, the client management maymake a determination as to the encryption level for specific Severityand Urgency associations. That information in conjunction with a MessageDefinition Form may be passed along to the CA's for Create SystemMessage for user menu driven messages. The actual algorithms that may bedeployed are application specific, and may be changed out on a veryfrequent basis such as every 12 hours to provide for higher levels ofmessage security. In addition to this provision for message security, itis anticipated that a minimum level of system availability andreliability can be maintained using a Global Quad redundant ServerArchitecture Network in SAS70 minimum facilities.

Routing Algorithm

After the message originator completes the message and selects SEND, themessage is encrypted at the Specified Encryption Level and sent to thecommunication server, where in a parallel form, the message is routed tothe first message stop, and optionally to a Client Message Archivedatabase. The general preferred transmission protocol acts as follows:

-   -   The Routing Algorithm involves the distributed server's        verification of the Primary Recipient being logged on, and if        that is false, the First Alternate, until that message stops        recipient list is exhausted.    -   The standard dead man switch is employed and the message is Auto        Forwarded to the next Recipient and where the First Recipient        would have entered their response to the message the system will        auto insert “Auto Forward—No User/Recipient was Logged On.”    -   The same procedure will be followed for each successive message        stop in the message chain.    -   If the client has a dead man provision for other routing “Only        in the Event”, it will be executed, otherwise the message is        terminated once it arrives at the final message stop.    -   The message is sent to a Message Archive Database for that        particular client, where the last two or more copies are        actively maintained until the message reaches its final        destination, at which time only the last/final message stop copy        is kept.        This completes the section from user SEND through encryption, to        first message stop recipient, and archive.        Conditions for Forwarding

Within this transmission protocol context there are three (3) currentlyanticipated conditions for a person to be considered “Not Logged On”:

-   -   The first condition is that they simply have not logged on yet.    -   The second condition is that the system, per client defined        protocol, has had the User logged off due to non-use, to help        control computer integrity/security and prevent unauthorized        access.    -   The third condition is that the user was logged on but there is        no file suggesting that they logged off or were disconnected by        the server due to inactivity. In this case the communications        server will send a notification to the client specified person        notifying them that there appears to be a technical anomaly with        that particular user.

While this transmission protocol is anticipated as optimal, one skilledin the art will recognize that many variations are possible based onsite and application specific customer requirements.

On-The-Fly Messaging (2700, 2800, 2900)

While the present invention may utilize the CA and associated MessageDefinition Forms to create a formalized and structured message deliverysystem/method, the present invention in some preferred embodiments alsoanticipates the use of on-the-fly messaging, in which messages aredelivered to a recipient list in a deterministic fashion that isspecifically structured at the time the message is created. This permitsimpromptu (on-the-fly) message creation and delivery in response to anynumber of unforeseeable environmental and situational conditions.

Top Level On-The-Fly Messaging Method (2700)

As depicted in the flowchart of FIG. 27 (2700), the method associatedwith this embodiment variant generally comprises the following steps:

-   -   (1) The CA or User logs in to the messaging system using the        authentication mechanisms discussed previously and selects        on-the-fly messaging from the dialog box dashboard interface        (2701);    -   (2) The CA/User selects the Create Message dialog box and        completes the messaging information including message        severity/urgency codes (2702);    -   (3) The user will be given the option of parallel (broadcast)        and/or cascade (serial sequential) message delivery (2703);    -   (4) If Parallel Messaging is selected, the primary recipients        and alternate recipients for that message stop can be selected        from Client Directory or entered manually. Once the message has        been created the user will proceed to TEST (See below) (2704);    -   (5) If Cascade Messaging is selected, the primary recipients and        alternate recipients for the message stops can be selected from        Client Directory or entered manually. The time to auto forward        for each message stop can be entered for each stop. Once the        message has been created the user will proceed to TEST (See        below) (2705);    -   (6) If a combination of both Parallel and Cascade: The user will        first be prompted to complete the options for the Parallel        Message, then the Cascade Message options, until all messages        stops are entered (2706);    -   (7) Test runs an internal validation algorithm to validate that        all selected recipients are valid and available/online with the        test results displayed for inspection and review (2707);    -   (8) If the TEST is unsuccessful, control is returned to step (2)        for correction of recipient failures (2708);    -   (9) The CA/User selects SEND to transmit the message to the        target message recipients (2709);    -   (10) Confirmation that the message has been sent is a unique        message identifier number with its priority relevant color        appearing in the Current Status section on the dashboard.        Message replies will be noted by a change in the color of that        message in the Current Status section indicating the message has        been updated with a reply, if the message is one that requires a        reply. If there is no reply the CA/User message transmission        activities are complete (2710); and    -   (11) Control is returned to the main dialog box messaging        dashboard (2711).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

Detailed on-the-Fly Messaging Method (2800, 2900)

One skilled in the art will recognize that many variations of theon-the-fly messaging method may be possible using the present invention.One example of a more robust embodiment of this teaching is illustratedin FIG. 28 (2800) and FIG. 29 (2900) that in combination expand on thegeneral teachings of the method illustrated in FIG. 27 (2700). Oneskilled in the art will recognize that other potential implementationsare possible within the scope of the claimed invention.

Message File Attachments (3000)

The present invention anticipates that messages may incorporate fileattachments under some situations. These attachments may includepictures, video, text and/or document files and other forms of digitaldata. As generally illustrated in FIG. 64 (6400) and other messagesystem dialogs illustrated herein, the attachment function can beincorporated into these menus in a variety of ways.

The user selects the Attachment tab from the system menu dashboard, thenuploads from the dropdown menu, to attach a file or picture. The CA mayselect the Create Message tab, Attachment tab from the drop down menu,and upload file/picture from the Attachment drop-down menu. The rest ofthis functionality will generally be accomplished on the client'scomputer separate from the message system dashboard.

An exemplary method associated with this file attachment functionalityis generally illustrated in FIG. 30 (3000) wherein the methodincorporates the following steps:

-   -   (1) From the client's computer chooses the Message System        Attachment Function from the message dialog box (3001);    -   (2) The drop down menu presents a message system upload applet        to upload the file to the message system (3002);    -   (3) The user chooses the file/picture they wish to upload and        issues the UPLOAD file function (Y303);    -   (4) The file is scanned for infections. The upload will be to        the message system upload secure server where the file/picture        will be scanned for infections. If an infection is found and its        removal is possible without destroying the file/picture, the        infection will be removed. Once the file or picture has been        scanned, a notification will appear on the user's dashboard to        indicate whether the file or picture is/is not available for use        (3004);    -   (5) If the file is acceptable, control passes to step (8)        (3005);    -   (6) The user is notified that the file is UNACCEPTABLE and the        file attachment process is terminated (3006);    -   (7) An unsuccessful return completion status is indicated and        control is returned step (1) (3007);    -   (8) The file attachment is archived to the messaging server; in        the event that a file or picture is available for use, the user        will have the option of sending another file/picture or        canceling the operation (3008);    -   (9) The user will be presented with a listing of available files        or pictures that can be attached to the message or viewed on        screen, outside of the client dashboard, but only if the file or        picture is found to be usable will the user be able to select        the file or picture to be included with the message (3009);    -   (10) The selected file or picture link(s) on the stored message        server (where it is archived for future reference) will then be        attached to message and forwarded as requested (3010); and    -   (11) A successful return completion status is indicated and        control is returned to step (1) with he recipient then able to        access the attachment on screen at its destination presentation        interface (3011).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

Anonymous Interrogator of Message (AIM) Scanner (3100)

The present invention anticipates integrated scanning of messages duringdata entry to check for threats to life and/or property that may requireimmediate attention. Any time the Severity or Urgency Selection ofANONYMOUS is chosen from any level of messaging menu, an AnonymousInterrogator of Message (AIM) scanning and review subsystem may beactivated. The sole purpose of this Anonymous Interrogator of Messageprogram is necessitated due to the threats that may be directed to oragainst the client personnel, facilities, or other client property, oractivities.

The Anonymous Interrogator of Message is a proactive discovery ofinsider threats and is designed to read in real time as a message isbeing composed. The Anonymous Interrogator of Message scans messages,but is initially thought to be optimally limited to ONLY interrogationof Anonymous messages.

The Anonymous Interrogator of Message scans Anonymous Messages forbehavior, certain words or certain phrases, to identify a clientcomputer location and allow client directed response in an attempt tointercept an employee before he or she becomes a danger to them orcompany or society. The system was developed to assist clients with theearliest internal and external terrorist threat identification.

Initially, the Anonymous Interrogator of Message will scan only theanonymous Messages generated by a client, but may be expanded if aclient chooses. But the very existence of such a program is sure tounnerve some client employees. If they—the client management choose tomake this information public within the enterprise. The real-time scanswork only on internal anonymous messages in the client's message system,not the client's computer network and or system. By monitoring for“anomalies” and predicting extreme behavior based on words and phrases,catastrophes can be prevented.

This is how the Anonymous Interrogator of Message detection enginesworks. As soon as anyone chooses the Anonymous Severity or Urgency, fromthe Menu, the message system will start the program interrogator. Thisprogram interrogator will look for in real-time as the message is beingentered those words and or phrases that the client has chosen to haveencoded into the program that they have deemed as dangerous orterrorist-centered in nature.

The Anonymous Interrogator of Message is contained within the systemframework of some preferred embodiments of the present invention, butall words or phrases are developed by and are included at the request ofthe client.

But the issue is not the scanning technology itself; it's how theinformation is used and whether it ultimately helps at all. Since thereis no real data publicly available to substantiate that any of thistechnology is preventing terrorist attacks or strengthening the clientfrom within, there is no definitive proof that as of today that thistype of program interrogator has really thwarted a threat. However, itcan be definitively stated that this technology will provide the abilityto react in as close to real-time as possible to the client system wherethe threat is being generated, and therefore in a best case scenarioprovide the opportunity to intercept the threatening originator as themessage is being generated.

A generalized method associated with the AIM process is illustrated inthe flowchart of FIG. 31 (3100), wherein the method comprises the stepsof:

-   -   (1) The client defines “suspicious” text/phrase combinations        (3109) in a text/phrase database (3101);    -   (2) The message originator activates the Create Message dialog        dashboard process (3102);    -   (3) The message originator enters message text via the message        entry interface (3103);    -   (4) The dialog box dashboard process dynamically compares        message originator input to the text/phrase database (3109)        using a variety of matching algorithms that may include direct        word matching and/or context sensitive text/phrase constructions        (3104);    -   (5) If a text/phrase match is found, control is passed to        step (7) (3105);    -   (6) Otherwise, message originator message entry continues as        normal until and end-of-message or SEND is entered by the        message originator with control passing to step (3) (3106);    -   (7) The suspicious message text/phrase match is reported to the        CA and/or management personnel (3107); and    -   (8) The suspicious message text/phrase match is logged to an        archive suspicious message database (3110) for later analysis        and/or review and control passes to step (3) (3108).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

New Message Arrival and Reply

The processing of new message arrivals and optional user replies willnow be discussed. Generally speaking, a given user must be logged intothe system to receive and reply to messages.

Upon receipt of a new message the entire dashboard will flash in thealternating colors of the Severity of the message as well as make analert sound upon arrival.

The dashboard will continue to flash in the alternating colors of theSeverity of the message and background color and continue to play thealert tones until the message receipt has been acknowledged by clickingon the dashboard.

The new incoming message will appear in the Current Status column at thetop position and will flash in the Severity of the message color andbackground color at a rate of two times per second, and will continue todo so until the auto forward timer has reached zero. At this point themessage will be auto forwarded to the next message stop and the messagewill now go into the steady-state and stop flashing. The user will nolonger have the ability to reply to message.

If the user wishes to examine any message located under the currentstatus section he only needs to hover the mouse over the message and anabbreviated amount of information will be displayed including the timeremaining till auto forward.

From the user dashboard select the Reply to Message tab and then clickthe message you wish to reply to in the Current Status section of thedashboard. Note: The clock at the top of the current status section willnow change to display the countdown until auto forward information forthe selected message. As can be seen on the dashboard picture theselected message will be displayed in the Original Message Here box.

In the Enter Reply Here box the user may enter their reply while keepingan eye on the auto forward countdown clock and word count remaining.Note: When the auto forward countdown clock reaches zero the messagewill auto forward to the next message stop and the system will terminateall reply to message functionalities and the message will auto-forwardto the next recipient with a notation: Auto Forwarded—No Action Taken.

When the user is satisfied with their reply they hit the SEND button toforward the message to the next recipient. Once the message has beensuccessfully sent to the next recipient(s), it will appear in theCurrent Status window with the steady-state color of the severityconfirming delivery of the message to the next recipient(s).

Message Auto-Forwarding (3200)

An important feature of the present invention messaging system is thatof “auto-forwarding on non-response” by a message recipient. Generallyspeaking, non-response from a message recipient causes the message to beauto-forwarded to the next individual recipient in the chain ofdesignated recipients. The methodology behind this behavior can be bestunderstood using the flowchart of FIG. 32 (3200), wherein the methodsteps comprise:

-   -   (1) The message arrives at a client presentation interface        (3201);    -   (2) A countdown timer is initialized with an Auto-Forward Time        value that represents the amount of time the message recipient        has to acknowledge and respond to the message, the timer is        started, and an asynchronous system trap (AST) is configured to        proceed to step (10) if the countdown timer reaches zero (3202);    -   (3) The client presentation message dialog box dashboard flashes        with the message severity color code and audibly sounds an        incoming message alert (3203);    -   (4) If the message is not acknowledged, control passes to        step (3) (3204);    -   (5) The message is moved to the Current Status section of the        client presentation interface dashboard dialog box and flashes        in the message severity code (3205);    -   (6) The user selects the Reply To Message option from the client        presentation interface dashboard dialog box (3206);    -   (7) The user selects the specific message to actually read and        possibly reply (3207);    -   (8) The client presentation interface dashboard dialog box        presents the user with text edit areas to read and reply to the        message (3208);    -   (9) The countdown timer is stopped, the AST is released, and the        message arrival method terminates (3209);    -   (10) An AST constantly monitors steps (3)-(8) to determine if        the countdown timer has not expired, and continues if the AST        has not been triggered by a countdown timer value of zero        (3210); and    -   (11) If the AST detects a countdown timer value of zero, the        message is automatically forwarded to the next recipient with a        message reply of “Auto Forwarded—No Action Taken” sent to the        message originator and all previous upstream message recipients        (3211).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

API Plug-in Modules (3300)

While the disclosed messaging system/method is very robust as to theintended purpose of reliably delivering messages to a variety of messagerecipients, the present invention anticipates that a wide variety ofadd-on software modules will be utilized in a spectrum of inventionembodiments and applications. This anticipated expansion ofsystem/method functionality is depicted generally in FIG. 33 (3300).

Referencing FIG. 33 (3300), the mechanism anticipated to be utilized inthis context is that of Application Program Interface (API) plug-insoftware modules (3320) that interface with and become a part of thecommunications process (3302) and which are installed via the use ofcomputer readable media (3321). This API plug-in support may incorporatethe use of software and/or hardware additions to the basicsystem/method. Some of the currently anticipated options will now bediscussed.

Hardware Plug-in Modules (3400)

As generally illustrated in FIG. 34 (3400), the present inventionanticipates incorporation of a wide variety of hardware devices andtheir associated API plug-in software, including but not limited to datainput terminals (3411, 3412), scanners (3421, 3422), still/video cameras(3431, 3432), audio input/output (3441, 3442), communications servers(3451, 3452), and portable/mobile devices such as tablets and/orsmartphones/mobile devices (3461, 3462) that may operate over a varietyof communication networks (3481) and be wireless (3482).

Secure Scanner Plug-in Modules (3500)

As generally illustrated in FIG. 34 (3400), the present inventionanticipates incorporation of a scanner (3421, 3422) within the contextof the messaging system. A typical implementation of this secure scannerplug-in is illustrated in FIG. 35 (3500).

This is anticipated as a purpose built stand-alone imaging systemcontaining a flatbed scanner and touch screen monitor to display thedashboard connected to a computer housed in a tamper-proof enclosure.The connection to the Internet is hardwired and tamper resistant andconstantly monitored. In commercial applications the unit is fixed toeither a wall or the floor or both to prevent its movement. Any attemptto gain entry to the unit will trigger a message that is sent to thelocal authorities and will cause the system to become inoperativerequiring an on-site reset.

The purpose of this secure scanner subsystem is to allow the scanning ofdocuments and transmission of documents under the messaging system. Itwill provide a secure, real-time, transmission of encrypted documentsfrom the originator to the recipient in minutes, as compared to thecurrent prior art secure document transmission methods utilizingpriority packaging, overnight mail, or private courier services.

This system provides complete integrity and security of all documents.The system provides the necessary legal constraints for bi-directionaltransmission of documents with signatures. The recipient will receive anoriginal scanned document whose integrity is digitally signed and can betracked from creation to reception with time in seconds to one tenthousandth accuracy.

The use of secure scanner applications are not limited to businesseswhere scanning and sending of documents is the normal course of businessor having the units placed in commercially accessible locations for useby the general public.

The amount of space necessary for scanning a document will be designedand built to meet the client's requirements for use. Items necessary foruse in a business environment of the secure scanner are relatively fewand include operational power, Internet connection, the documents to bescanned, and the ability to select the recipient from the messagerecipient database. If the recipient is not in the database then therecipients' information may be manually entered. Items necessary for usein a commercial environment of the secure scanner are relatively few andinclude operational power, internet connection, a credit card, thedocuments, and as a minimum: the e-mail or IP address of the recipient.

In order to support secure document transmission with in situationswhere a single document is to be signed securely by two individuals, thedocument is securely scanned into the messaging system and transmittedto both parties, with each party signing the document separately. Thenthe signed original documents are transmitted to the opposing party forreview and acceptance, in addition to archival of the documents withinthe messaging system infrastructure.

An example of this methodology can be seen in FIG. 35 (3500), wherein aninitial user (3511) prepares/procures a document (3510) for signing andscans this using a secure scanner (3512) that then interacts with thecommunication process and/or its scanner API (3530) to store thedocument within a message database (3531). A second user (3521) withcorresponding scanner (3522) may also perform similar operations to loadone or more documents (3520) onto the message database (3531) via theAPI (3530).

The document(s) (3510, 3520) are then presented on the clientpresentation interfaces (3513, 3523) for user signature (3514, 3524) andthe signed documents are then securely delivered electronically (3515,3525) to the opposing party using the communication process/scanner API(3530) after being stored in a signed document archive (3532). Documentsignatures (3514, 3524) can be accomplished via video/still pictures(FIG. 34 (3432)), audio confirmation (FIG. 34 (3442)), secure serverencryption authentication keys (FIG. 34 (3452)), tablet interfaces (FIG.34 (3462)), and/or other biometric authentication interfaces.

Secure Document Signing/Scanner Method/(300)

The secure document scanner application generally illustrated in FIG. 35(3500) may have associated with it a corresponding secure documentsigning/scanner method comprising the following method steps:

-   -   (1) One or both of USER-1 or USER-2 scans a document on a secure        scanner (3601);    -   (2) The secure scanner transmits the document to a message        archive database (3602);    -   (3) The communication process transmits the stored document to        USER-1 and USER-2 simultaneously (3603);    -   (4) USER-1 “signs” the document using any authorized signature        method, including but not limited to picture identification,        voiceprint identification, handwriting sample, encryption key,        password, etc. (3604);    -   (5) The signed USER-1 document is archived in the message        database (3605);    -   (6) USER-2 “signs” the document using any authorized signature        method, including but not limited to picture identification,        voiceprint identification, handwriting sample, encryption key,        password, etc. (3606);    -   (7) The signed USER-2 document is archived in the message        database (3607);    -   (8) The communications process combines the USER-1 and USER-2        documents to form a combined USER-12 document on the message        server (3608);    -   (9) The USER-12 document is transmitted to USER-1 and USER-2 via        message by the communications process to verify two-party        signature of both USER-1 and USER-2 (3609); and    -   (10) The secure document signing/scanner method terminates        (3610).

One skilled in the art will recognize that these method steps may beindividually eliminated, augmented, modified, and/or rearranged withoutlimiting the teachings of the present invention.

PLC Plug-in Modules (3700)

A programmable logic controller (PLC) or programmable controller is adigital computer used for the automation of electromechanical processes,such as control of machinery on factory assembly lines, amusement rides,or light fixtures. PLCs are used in many industries. Unlikegeneral-purpose computers, the PLC is designed for multiple inputs andoutputs, extended temperature ranges, immunity to electrical noise, andresistance to vibration and impact. Programs to control machineoperation are typically stored in battery-backed-up or non-volatilememory. A PLC is an example of a hard real-time system since outputresults must be produced in response to input conditions within abounded time or unintended operation will result.

PLCs have built in communications ports, usually 9-pin RS-232, butoptionally EIA-485 or Ethernet. Modbus, BACnet or DF1 is usuallyincluded as one of the communications protocols. Other options includevarious field busses such as DeviceNet or Profibus. One skilled in theart will recognize that there are other communications protocols thatmay be commonly used in industry within the scope of this teaching.

Most modern PLCs can communicate over a network to another system suchas computers running a Supervisory Control and Data Acquisition (SCADA)system or web browser. PLCs used in larger I/O systems may havepeer-to-peer (P2P) communication between processors. This allowsseparate parts of a complex process to have individual control whileallowing the subsystems to co-ordinate over the communication link.These communication links are also often used for HMI devices such askeypads or PC-type workstations.

As generally illustrated in FIG. 37 (3700), the present inventionanticipates that some API interface (3720) (and associatednon-transitory computer readable medium (3721)) may be provide for PLCcontrol within the messaging system, possibly with the use of anadditional license or other authentication access mechanism. With thiscontext, the machine PLC will be tab accessible by those with the propercredentials from the message dashboard. The use of a centralized commandlisting wherein predefined decisions are stored in a message definitionformat will simplify the process of selection for the user in situationswhere the PLC (3708) (with its associated non-transitory computerreadable medium containing control software (3709) and associatedindustrial equipment processes (3719)) must be controlled within themessaging framework.

The authorized user can then make a selection of the appropriate machineand PLC control codes based on the severity and urgency to send amessage. A notification verifies the message was sent to the rightmachines and/or PLC's in the right order and designated timeframe.Authorized clients that have machines/PLCs with communicationscapabilities tied to a networked can use the messaging system to allowcommunications to/from PLCs when necessary.

Depending upon the magnitude and scope of the event there well may bedifferent machine codes and PLC commands sent in parallel to differentmachines and PLC's. This provides real-time updates and responses, forthe Command Director originating the message, by machine and PLC. Due tothe real-time informational feedback it is possible for the messageoriginator to make efficient, informed decisions based on theinformation to discontinue a particular command set and/or send anothercommand set. The use of this information would be of critical valueduring the event as well as during the post event investigations andwill be pivotal in the development of better command and controlstructures to be used in the future. The abilities of the messagingsystem to be utilized in these circumstances allow scalability forfuture expansion of the messaging system to control a wide variety ofdisasters and other serious situations in which intelligent andimmediate machine control may result in reduced property and/or lifeloss.

Licensing Plug-in Modules (3800)

The present invention anticipates that a variety of licensing plug-inAPI modules may be added to the basic communication process as depictedin FIG. 38 (3800), with the API (3820) optionally comprising computerreadable media for license keys and other license specific enablementinformation. Included within this scope is the use of security tokensand the like to enable access to specific messaging functions and/orspecific PLC (3808) controls.

Voice Recognition Interface

The present invention anticipates that the use of voice recognitionsoftware within the context of the messaging system. As generallyillustrated in FIG. 34 (3442), the use of audio input as an auxiliarydata stream is anticipated by the API plug-in structure of the messagingsystem/method. While this voice recognition API may support disabledusers, the system can also be utilized by non-impaired individuals.

People with disabilities can benefit from the use of speech recognitionprograms. Individuals who have physical limitations ranging from mildrepetitive stress injuries to involved disabilities that preclude theuse of conventional computer input devices. Speech recognition is also abenefit to the deaf for the creation of voicemail to text, relayservices, and closed-captioned telephony. Individuals with learningdisabilities who have problems with thought-to-paper communications canbenefit from the use of this type of software.

While many speech recognition applications are available, the presentinvention anticipates a commercial software package such as DRAGONNATURALLYSPEAKING®/DICTATE® brands of speech recognition software wouldbe suitable for this use. This application is a speech recognitionsoftware package developed and sold by Nuance Communications forGUI-based personal computers, including 32-bit and 64-bit systems and avariety of operating systems.

DRAGON NATURALLYSPEAKING® brand of speech recognition software utilizesa minimal user interface. The software has three primary areas offunctionality: dictation, text-to-speech and command input. The user isable to dictate and have speech transcribed as written text, have adocument synthesized as an audio stream, or issue commands that arerecognized as such by the message System Program. In addition voiceprofiles can be accessed through different computers in a networkedenvironment, although the audio hardware and configuration must beidentical on both machines. The present invention anticipates that thesecommercial software packages can be integrated into the user messaginginterface to permit dictation, text-to-speech, and a variety of commandinputs to be driven audibly without the need for a tactile humanmessaging interface.

Mobile Devices and Multiprotocol Label Switching (MPLS) (3900)

The present invention anticipates the use of mobile devices as thehardware platform from which message are originated and on whichmessages are received. Within this context, the use of MultiprotocolLabel Switching (MPLS) is specifically anticipated as an optimalcommunication methodology for data transmission to/from the mobiledevices. Multiprotocol Label Switching (MPLS) is a mechanism inhigh-performance telecommunication networks that directs data from onenetwork node to the next based on short path labels rather than longnetwork addresses, avoiding complex lookups in a routing table. Thelabels identify virtual links (paths) between distant nodes rather thanendpoints. MPLS can encapsulate packets of various network protocols.MPLS supports a range of access technologies, including T1/E1, ATM,Frame Relay and DSL.

Use of Mobile Broadband to Connect to the Internet

As generally illustrated in FIG. 39 (3900), mobile devices (3901, 3902)include smart devices such as: tablet computers, smartphones, mobiledevices, notebooks, etc. Mobile broadband technology, also calledwireless wide area network (WWAN) technology (3903), provides mobileInternet connectivity. Use of mobile broadband generally requires a datacard and a data plan with a mobile broadband provider. After procurementof a smart device and data plan, the Subscriber Identity Module (SIM)and the mobile broadband service for the SIM is activated by the mobileservices provider.

Messaging System and Mobile Applet

Mobile Application Definition—Also called mobile apps, this is a termused to describe Internet applications that run on smartphones and othermobile devices. Mobile applications grant users access to Internetservices more commonly accessed on desktop or notebook computers. Forthe purposes of the present invention the mobile app is the mobile-basedmessaging System client.

Mobile System Log on (4000)

The Mobile System user will be presented with the logon screen asgenerally illustrated in FIG. 40 (4000). In this instance theauthenticator code can be generated via the watch FOB and or use of amobile application authenticator code generator. The mobile applicationuser will enter password and authenticator code and will generally belimited to three attempts to logon. If the user is unsuccessful afterthe third attempt they will be locked out from a further attempt andwill need to contact the certified administrator (CA) for assistance.

A CA will use the same warning code protocol. See warning code protocolfor additional information. Upon successful logon, the user/CA will beable to utilize any services for which they are licensed. They will bepresented with either the user or CA mobile user dashboard.

Messaging System Using Mobile Application

The messaging system mobile applet will allow a user/CA (hereafterreferred to simply as user) access to various services within themessaging application for which they are properly licensed (message onthe fly, attachment, interactive checklist, machine controls, etc.) onany mobile device. Certain application functionalities may be limiteddue to size and scope of use and viewing on a mobile device.

Technical Process

The Mobile Applet will provide the ability to communicate on the WWANwhich is displayed in FIG. 39 (3900). Once the WWAN's connection to theMPLS is made the mobile application functionality will be appropriatelyscaled for use on a mobile device. The user of the smartphone or mobiledevice will have to determine what data/files to display based on thescreen size of the smart phone or mobile device. The standard user willneed to update their administration files to show their contact prioritypreferences, i.e. desktop first, notebook second, mobile device, etc.The system may select contacts based on the selected preferences. As inall cases, if a user is not online or available the message will simplylook for the next alternate. In the event where there is no alternateavailable, the message will auto forward to the next recipient in thechain.

The mobile system application will provide the CA with the sameabilities to create a message, modify a message, or create a usermessage, reply to a message, select contact preferences and/or read amessage. The mobile system application is not necessarily intended as areplacement for a desktop computer but may be scaled for use and viewingon the mobile device.

System/Method Variations

The present invention anticipates a wide variety of system/methodvariations in the basic theme of construction. The examples presentedpreviously do not represent the entire scope of possible usages. Theyare meant to cite a few of the almost limitless possibilities. Somepreferred system/method embodiments include the following:

-   -   An embodiment wherein the message is classified based on a        customizable hierarchy level.    -   An embodiment wherein the message is classified based on a        hierarchy level.    -   An embodiment wherein the message is classified based on a        hierarchy level, the hierarchy level comprising one or more        customizable hierarchy status markers.    -   An embodiment wherein the message is classified based on a        customizable hierarchy level, the hierarchy level comprising one        or more customizable hierarchy status markers.    -   An embodiment wherein the message is classified based on        severity level.    -   An embodiment wherein the message is classified based on        severity level, the severity level further comprising SEVERE,        SERIOUS, MODERATE, MINOR, and/or ANONYMOUS levels.    -   An embodiment wherein the message is classified based on urgency        level.    -   An embodiment wherein the message is classified based on urgency        level, the urgency level further comprising IMMEDIATE, URGENT,        NEED SOON, INFORMATIONAL ONLY, and/or ANONYMOUS levels.    -   An embodiment wherein the message is classified based on a        specific menu selection from the source user interface.    -   An embodiment wherein the message is classified based on a        specific menu selection from the source user interface, the        message classification further comprising LIFE CRITICAL/MISSION        CRITICAL, CRITICAL, URGENT, CORRECTIVE ACTION/AUDIT, CONTINUOUS        IMPROVEMENT/SUGGESTION, INFORMATION TRANSFER, and/or ANONYMOUS        REPORTING.    -   An embodiment wherein the message is encrypted by the source        messaging client process.    -   An embodiment wherein the message is encrypted when stored on        the message database.    -   An embodiment wherein the message is decrypted by the target        messaging client process.    -   An embodiment wherein the predetermined time is set individually        for each of the target system interfaces.    -   An embodiment wherein the predetermined time is based on        calendar-based information.    -   An embodiment wherein the transmission of the message to the        target system interface is sequentially prioritized via use of a        hierarchical target message thread.    -   An embodiment wherein the source messaging client process        receives conditional branching requirements for the target        system interface via the source messaging system interface.    -   An embodiment wherein the message host process further comprises        anticipatory message queuing wherein the message is sent to the        target system interface and the next target system interface        addressed by a hierarchical target message address list with        information indicating that the next target system interface is        to wait to process the message until instructed to do so by the        message host process.    -   An embodiment wherein the target system interface is polled to        determine if it is online/available, and if not, the target        system interface is skipped and the next target system interface        addressed by a hierarchical target message address list is        utilized as the new target for delivery of the message.

One skilled in the art will recognize that other embodiments arepossible based on combinations of elements taught within the aboveinvention description.

Generalized Computer Usable Medium

As generally illustrated in FIG. 1 (0100), the system embodiments of thepresent invention can incorporate a variety of computer readable media(0105) that comprise non-transitory computer usable medium havingcomputer readable code means embodied therein. One skilled in the artwill recognize that the software associated with the various processesdescribed herein can be embodied in a wide variety of computeraccessible media from which the software is loaded and activated.Pursuant to In re Beauregard, 35 USPQ2d 1383 (U.S. Pat. No. 5,710,578),the present invention anticipates and includes this type of computerreadable media within the scope of the invention.

CONCLUSION

A messaging system and method with dead man switching providing forhierarchical delivery of messages based on selected message hierarchylevels with controlled delivery/response timing is disclosed. The systemand method incorporates a messaging host that communicates with amessaging source client that creates and prioritizes a message andtargets address(es) for the message. This message is then transmitted tothe target address(es) using a hierarchical transmission thread havingset limits on response times for each address within the thread.Reception of the message by each target(s) produces visual and/orauditory notification at the target(s). Messages are automaticallyforwarded to remaining target(s) within the thread upon expiration of atimer should the target(s) fail to respond to the message within apredetermined time. Failure of the target(s) to respond to themessage(s) is reported bi-directionally along the thread and forwardedto remaining target(s) in the thread.

The invention claimed is:
 1. A non-transitory computer usable mediumhaving computer-readable program code comprising a messaging methodwherein said method controls a messaging system comprising: (a) acommunications server having— 1) message database; 2) message fileserver; 3) message host process operating on said file server; and 4) anon-transitory computer readable medium in communication with aprocessor executing computer instructions to perform said message hostprocess; (b) a remote source message system interface stored in memoryfor data entry and generation of messages on the communication server;(c) source messaging client process residing on the communication serverand monitoring status of acceptance/reading by target; (d) anon-transitory computer readable medium in communication with aprocessor executing computer instructions to perform said sourcemessaging client process; (e) a remote target messaging system interfacestored in memory for receiving, displaying and replying to said messagedata; (f) target messaging client process residing on the communicationserver; and (g) a non-transitory computer readable medium incommunication with a processor executing computer instructions toperform said target messaging client process; wherein, said sourcemessaging client process receives the messages and messageseverity/urgency classifications from a source user via said sourcemessaging system; said source messaging system transmits said messagesand said message severity/urgency classifications to said message hostprocess for storage on said message database via said message fileserver; said message host process transmits said message and saidmessage severity/urgency classification to said target system interfacevia a communications medium for display by said target system interfaceunder control of said target message process; said target messageprocess responds to said message host process if said message isexamined on said target system interface by a user; said message hostprocess initiates a dead man messaging process that waits apredetermined amount of time for said response to said message by saiduser and if said predetermined time is exceeded, said message is updatedand forwarded to another target system interface for inspection byanother user; and said message host process reports to said sourcemessage process the status of said message to each of said targetsystems; with said method comprising the steps of: (1) logging onto thecommunication server by a message originator through the message entryinterface (2) Entering data into a message entry interface by a messageoriginator and creating a message within the communication server; (3)entering a message severity/urgency classification data from saidmessaging source interface for message residing on communicationsserver; (4) transmitting said message said message severity/urgencyclassification to said message host and storing the message on saidmessage database via said communications server; (5) traversing ahierarchical target message thread to determine the targets for saidmessage; (6) selecting the next message target within said hierarchicalmessage thread; (7) determining if said hierarchical message thread isexhausted, and if so, proceeding to step (11); (8) transmitting saidmessage within the communications server to the currently selectedremote target system interface within said hierarchical message thread;(9) determining if said message has been read by said currently selectedremote target system interface within said hierarchical message thread,and if so, proceeding to step (12); (10) determining if a targetresponse timer has expired, and if not, proceeding to said step (9);(11) transmitting said message to said currently selected remote targetsystem interface within said hierarchical message thread; (12) reportingto said source messaging interface that message reception has failed andproceeding to said step (6); (13) reporting to said source messaginginterface that said message has been received and returning any optionaluser comment; and (14) optionally entering comments on said messageand/or passing through said message to said current or anotherhierarchical message thread.
 2. The non-transitory computer usablemedium of claim 1 wherein said message is classified based on ahierarchy level.
 3. The non-transitory computer usable medium of claim 1wherein said message is classified based on a customizable hierarchylevel.
 4. The non-transitory computer usable medium of claim 1 whereinsaid message is classified based on a hierarchy level, said hierarchylevel comprising one or more customizable hierarchy status markers. 5.The non-transitory computer usable medium of claim 1 wherein saidmessage is classified based on a customizable hierarchy level, saidhierarchy level comprising one or more customizable hierarchy statusmarkers.
 6. The non-transitory computer usable medium of claim 1 whereinsaid message is classified based on severity level.
 7. Thenon-transitory computer usable medium of claim 1 wherein said message isclassified based on severity level, said severity level furthercomprising SEVERE, SERIOUS, MODERATE, MINOR, and/or ANONYMOUS levels. 8.The non-transitory computer usable medium of claim 1 wherein saidmessage is classified based on urgency level.
 9. The non-transitorycomputer usable medium of claim 1 wherein said message is classifiedbased on urgency level, said urgency level further comprising IMMEDIATE,URGENT, NEED SOON, INFORMATIONAL ONLY, and/or ANONYMOUS levels.
 10. Thenon-transitory computer usable medium of claim 1 wherein said message isclassified based on a specific menu selection from said source userinterface.
 11. The non-transitory computer usable medium of claim 1wherein said message is classified based on a specific menu selectionfrom said source user interface, said message classification furthercomprising LIFE CRITICAL/MISSION CRITICAL, CRITICAL, URGENT, CORRECTIVEACTION/AUDIT, CONTINUOUS IMPROVEMENT/SUGGESTION, INFORMATION TRANSFER,and/or ANONYMOUS REPORTING.
 12. The non-transitory computer usablemedium of claim 1 wherein said message is encrypted by said sourcemessaging client process.
 13. The non-transitory computer usable mediumof claim 1 wherein said message is encrypted when stored on said messagedatabase.
 14. The non-transitory computer usable medium of claim 1wherein said message is decrypted by said target messaging clientprocess.
 15. The non-transitory computer usable medium of claim 1wherein said predetermined time is set individually for each of saidtarget system interfaces.
 16. The non-transitory computer usable mediumof claim 1 wherein said predetermined time is based on calendar-basedinformation.
 17. The non-transitory computer usable medium of claim 1wherein the transmission of said message to said target system interfaceis sequentially prioritized via use of a hierarchical target messagethread.
 18. The non-transitory computer usable medium of claim 1 whereinsaid source messaging client process receives conditional branchingrequirements for said target system interface via said source messagingsystem interface.
 19. The non-transitory computer usable medium of claim1 wherein said message host process further comprises anticipatorymessage queuing wherein said message is sent to said target systeminterface and the next target system interface addressed by ahierarchical target message address list with information indicatingthat said next target system interface is to wait to process saidmessage until instructed to do so by said message host process.
 20. Thenon-transitory computer usable medium of claim 1 wherein said targetsystem interface is polled to determine if it is online/available, andif not, said target system interface is skipped and the next targetsystem interface addressed by a hierarchical target message address listis utilized as the new target for delivery of said message.
 21. Amessaging system comprising: (a) a communications server having— 1) amessage database; 2) a message file server; 3) a message host processoperating on said file server; and 4) a non-transitory computer readablemedium in communication with a processor executing computer instructionsto perform said message host process; (b) a remote source message systeminterface stored in memory for data entry and generation of messages onthe communication server; (c) source messaging client process residingon the communication server and monitoring status of acceptance/readingby target; (d) a non-transitory computer readable medium incommunication with a processor executing computer instructions toperform said source messaging client process; (e) a remote targetmessaging system interface stored in memory for receiving, displayingand replying to said message; (f) target messaging client processresiding on the communication server; and (g) non-transitory computerreadable medium in communication with a processor executing computerinstructions to perform said target messaging client process; wherein,said source messaging client process receives the messages and messageseverity/urgency classifications from a source user via said sourcemessaging system; said source messaging system transmits said messagesand said message severity/urgency classifications to said message hostprocess for storage on said message database via said message fileserver; said message host process transmits said message and saidmessage severity/urgency classification to said target system interfacevia a communications medium for display by said target system interfaceunder control of said target message process; said target messageprocess responds to said message host process if said message isexamined on said target system interface by a target user; said messagehost process initiating a dead man messaging method that waits apredetermined amount of time for said response to said message by saidtarget user and if said predetermined time is exceeded, said message isupdated and forwarded to another target system interface for inspectionby another target user; and said message host process reports to saidsource message process the status of said message to each of said targetsystems with said messaging system utilizing a processor to perform thesteps of: (1) logging onto the communication server by a messageoriginator through the message entry interface (2) entering data into amessage entry interface by a message originator and creating a messagewithin the communication server; (3) entering a message severity/urgencyclassification data from said messaging source interface for messageresiding on communications server; (4) transmitting said message saidmessage severity/urgency classification to said message host and storingthe message on said message database via said communications server; (5)traversing a hierarchical target message thread to determine the targetsfor said message; (6) selecting the next message target within saidhierarchical message thread; (7) determining if said hierarchicalmessage thread is exhausted, and if so, proceeding to step (11); (8)transmitting said message within the communications server to thecurrently selected remote target system interface within saidhierarchical message thread; (9) determining if said message has beenread by said currently selected remote target system interface withinsaid hierarchical message thread, and if so, proceeding to step (12);(10) determining if a target response timer has expired, and if not,proceeding to said step (9); (11) transmitting said message to saidcurrently selected remote target system interface within saidhierarchical message thread; (12) reporting to said source messaginginterface that message reception has failed and proceeding to said step(6); (13) reporting to said source messaging interface that said messagehas been received and returning any optional user comment; and (14)optionally entering comments on said message and/or passing through saidmessage to said current or another hierarchical message thread.
 22. Themessaging system of claim 21 wherein said message is classified based ona customizable hierarchy level.
 23. The messaging system of claim 21wherein said message is classified based on a hierarchy level.
 24. Themessaging system of claim 21 wherein said message is classified based ona hierarchy level, said hierarchy level comprising one or morecustomizable hierarchy status markers.
 25. The messaging system of claim21 wherein said message is classified based on a customizable hierarchylevel, said hierarchy level comprising one or more customizablehierarchy status markers.
 26. The messaging system of claim 21 whereinsaid message is classified based on severity level.
 27. The messagingsystem of claim 21 wherein said message is classified based on severitylevel, said severity level further comprising SEVERE, SERIOUS, MODERATE,MINOR, and/or ANONYMOUS levels.
 28. The messaging system of claim 21wherein said message is classified based on urgency level.
 29. Themessaging system of claim 21 wherein said message is classified based onurgency level, said urgency level further comprising IMMEDIATE, URGENT,NEED SOON, INFORMATIONAL ONLY, and/or ANONYMOUS levels.
 30. Themessaging system of claim 21 wherein said message is classified based ona specific menu selection from said source user interface.
 31. Themessaging system of claim 21 wherein said message is classified based ona specific menu selection from said source user interface, said messageclassification further comprising LIFE CRITICAL/MISSION CRITICAL,CRITICAL, URGENT, CORRECTIVE ACTION/AUDIT, CONTINUOUSIMPROVEMENT/SUGGESTION, INFORMATION TRANSFER, and/or ANONYMOUSREPORTING.
 32. The messaging system of claim 21 wherein said message isencrypted by said source messaging client process.
 33. The messagingsystem of claim 21 wherein said message is encrypted when stored on saidmessage database.
 34. The messaging system of claim 21 wherein saidmessage is decrypted by said target messaging client process.
 35. Themessaging system of claim 21 wherein said predetermined time is setindividually for each of said target system interfaces.
 36. Themessaging system of claim 21 wherein said predetermined time is based oncalendar-based information.
 37. The messaging system of claim 21 whereinthe transmission of said message to said target system interface issequentially prioritized via use of a hierarchical target messagethread.
 38. The messaging system of claim 21 wherein said sourcemessaging client process receives conditional branching requirements forsaid target system interface via said source messaging system interface.39. The messaging system of claim 21 wherein said message host processfurther comprises anticipatory message queuing wherein said message issent to said target system interface and the next target systeminterface addressed by a hierarchical target message address list withinformation indicating that said next target system interface is to waitto process said message until instructed to do so by said message hostprocess.
 40. The messaging system of claim 21 wherein said target systeminterface is polled to determine if it is online/available, and if not,said target system interface is skipped and the next target systeminterface addressed by a hierarchical target message address list isutilized as the new target for delivery of said message.
 41. A messagingmethod wherein said method controls a messaging system comprising: (a) acommunications server having— 1) a message database; 2) a message fileserver; 3) a message host process operating on said file server; and 4)a non-transitory computer readable medium in communication with aprocessor executing computer instructions to perform said message hostprocess; (b) a remote source message system interface stored in memoryfor data entry and generation of messages on the communication server;(c) source messaging client process residing on the communication serverand monitoring status of acceptance/reading by target; (d)non-transitory computer readable medium in communication with aprocessor executing computer instructions to perform said sourcemessaging client process; (e) a remote target messaging system interfacestored in memory for receiving, displaying and replying to said messagedata; (f) target messaging client process residing on the communicationserver; and (g) non-transitory computer readable medium in communicationwith a processor executing computer instructions to perform said targetmessaging client process; wherein, said source messaging client processreceives the messages and message severity/urgency classifications froma source user via said source messaging system; said source messagingsystem transmits said messages and said message severity/urgencyclassifications to said message host process for storage on said messagedatabase via said message file server; said message host processtransmits said message and said message severity/urgency classificationto said target system interface via a communications medium for displayby said target system interface under control of said target messageprocess; said target message process responds to said message hostprocess if said message is examined on said target system interface by auser; said message host process initiating a dead man messaging methodthat waits a predetermined amount of time for said response to saidmessage by said user and if said predetermined time is exceeded, saidmessage is updated and forwarded to another target system interface forinspection by another user; and said message host process reports tosaid source message process the status of said message to each of saidtarget systems; with said method comprising the steps of: (1) loggingonto the communication server by a message originator through themessage entry interface (2) entering data into a message entry interfaceby a message originator and creating a message within the communicationserver; (3) entering a message severity/urgency classification data fromsaid messaging source interface for message residing on communicationsserver; (4) transmitting said message said message severity/urgencyclassification to said message host and storing the message on saidmessage database via said communication server; (5) traversing ahierarchical target message thread to determine the targets for saidmessage; (6) selecting the next message target within said hierarchicalmessage thread; (7) determining if said hierarchical message thread isexhausted, and if so, proceeding to step (11); (8) transmitting saidmessage within the communications server to the currently selectedremote target system interface within said hierarchical message thread;(9) determining if said message has been read by said currently selectedremote target system interface within said hierarchical message thread,and if so, proceeding to step (12); (10) determining if a targetresponse timer has expired, and if not, proceeding to said step (9);(11) transmitting said message to said currently selected remote targetsystem interface within said hierarchical message thread; (12) reportingto said source messaging interface that message reception has failed andproceeding to said step (6); (13) reporting to said source messaginginterface that said message has been received and returning any optionaluser comment; and (14) optionally entering comments on said messageand/or passing through said message to said current or anotherhierarchical message thread.
 42. The messaging method of claim 41wherein said message is classified based on a hierarchy level.
 43. Themessaging method of claim 41 wherein said message is classified based ona customizable hierarchy level.
 44. The messaging method of claim 41wherein said message is classified based on a customizable hierarchylevel, said hierarchy level comprising one or more customizablehierarchy status markers.
 45. The messaging method of claim 41 whereinsaid message is classified based on a hierarchy level, said hierarchylevel comprising one or more customizable hierarchy status markers. 46.The messaging method of claim 41 wherein said message is classifiedbased on severity level.
 47. The messaging method of claim 41 whereinsaid message is classified based on severity level, said severity levelfurther comprising SEVERE, SERIOUS, MODERATE, MINOR, and/or ANONYMOUSlevels.
 48. The messaging method of claim 41 wherein said message isclassified based on urgency level.
 49. The messaging method of claim 41wherein said message is classified based on urgency level, said urgencylevel further comprising IMMEDIATE, URGENT, NEED SOON, INFORMATIONALONLY, and/or ANONYMOUS levels.
 50. The messaging method of claim 41wherein said message is classified based on a specific menu selectionfrom said source user interface.
 51. The messaging method of claim 41wherein said message is classified based on a specific menu selectionfrom said source user interface, said message classification furthercomprising LIFE CRITICAL/MISSION CRITICAL, CRITICAL, URGENT, CORRECTIVEACTION/AUDIT, CONTINUOUS IMPROVEMENT/SUGGESTION, INFORMATION TRANSFER,and/or ANONYMOUS REPORTING.
 52. The messaging method of claim 41 whereinsaid message is encrypted by said source messaging client process. 53.The messaging method of claim 41 wherein said message is encrypted whenstored on said message database.
 54. The messaging method of claim 41wherein said message is decrypted by said target messaging clientprocess.
 55. The messaging method of claim 41 wherein said predeterminedtime is set individually for each of said target system interfaces. 56.The messaging method of claim 41 wherein said predetermined time isbased on calendar-based information.
 57. The messaging method of claim41 wherein the transmission of said message to said target systeminterface is sequentially prioritized via use of a hierarchical targetmessage thread.
 58. The messaging method of claim 41 wherein said sourcemessaging client process receives conditional branching requirements forsaid target system interface via said source messaging system interface.59. The messaging method of claim 41, wherein said message host processfurther comprises anticipatory message queuing wherein said message issent to said target system interface and the next target systeminterface addressed by a hierarchical target message address list withinformation indicating that said next target system interface is to waitto process said message until instructed to do so by said message hostprocess.
 60. The messaging method of claim 41 wherein said target systeminterface is polled to determine if it is online/available, and if not,said target system interface is skipped and the next target systeminterface addressed by a hierarchical target message address list isutilized as the new target for delivery of said message.
 61. Anon-transitory computer usable medium having computer-readable programcode comprising a messaging method wherein said method controls amessaging system comprising: (a) a communications server having— 1) amessage database; 2) a message file server; 3) a message host processoperating on said file server; and 4) a non-transitory computer readablemedium in communication with a processor executing computer instructionsto perform said message host process; (b) a remote source message systeminterface stored in memory for data entry and generation of messages onthe communication server; (c) a source messaging client process residingon the communication server and monitoring status of acceptance/readingby target; (d) a non-transitory computer readable medium incommunication with a processor executing computer instructions toperform said source messaging client process; (e) a remote targetmessaging system interface stored in memory for receiving, displayingand replying to said message data; (f) a target messaging client processresiding on the communication server; and (g) a non-transitory computerreadable medium in communication with a processor executing computerinstructions to perform said target messaging client process; wherein,said source messaging client process receives the messages and messageseverity/urgency classifications from a source user via said sourcemessaging system; said source messaging system transmits said messagesand said message severity/urgency classifications to said message hostprocess for storage on said message database via said message fileserver; said message host process transmits said message and saidmessage severity/urgency classification to said target system interfacevia a communications medium for display by said target system interfaceunder control of said target message process; said target messageprocess responds to said message host process if said message isexamined on said target system interface by a user; said message hostprocess initiating a dead man messaging method that waits apredetermined amount of time for said response to said message by saiduser and if said predetermined time is exceeded, said message isretransmitted to another target system interface for inspection byanother user; and said message host process reports to said sourcemessage process the status of attempts to deliver said message to eachof said target systems; with said method comprising the steps of: (1)logging onto the communication server by a message originator throughthe message entry interface (2) entering data into a message entryinterface by a message originator and creating a message within thecommunication server; (3) entering a message severity/urgencyclassification data from said messaging source interface for messageresiding on communications server; (4) transmitting said message saidmessage severity/urgency classification to said message host and storingthe message on said message database via said file server; (5)traversing a hierarchical target message thread to determine the targetsfor said message; (6) selecting the next message target within saidhierarchical message thread; (7) determining if said hierarchicalmessage thread is exhausted, and if so, proceeding to step (10); (8)transmitting said message within the communications server to thecurrently selected remote target system interface within saidhierarchical message thread; (9) determining if said message has beenread by said currently selected remote target system interface withinsaid hierarchical message thread, and if so, proceeding to step (12);(10) determining if a target response timer has expired, and if not,proceeding to said step (9); (11) transmitting said message to saidcurrently selected remote target system interface within saidhierarchical message thread; (12) reporting to said source messaginginterface that message reception has failed and proceeding to said step(6); (13) reporting to said source messaging interface that said messagehas been received and returning any optional user comment; and (14)optionally entering comments on said message and/or passing through saidmessage to said current or another hierarchical message thread.
 62. Thenon-transitory computer usable medium of claim 61 wherein said messageis classified based on a hierarchy level.
 63. The non-transitorycomputer usable medium of claim 61 wherein said message is classifiedbased on a customizable hierarchy level.
 64. The non-transitory computerusable medium of claim 61 wherein said message is classified based on ahierarchy level, said hierarchy level comprising one or morecustomizable hierarchy status markers.
 65. The non-transitory computerusable medium of claim 61 wherein said message is classified based on acustomizable hierarchy level, said hierarchy level comprising one ormore customizable hierarchy status markers.
 66. The non-transitorycomputer usable medium of claim 61 wherein said message is classifiedbased on severity level.
 67. The non-transitory computer usable mediumof claim 61 wherein said message is classified based on severity level,said severity level further comprising SEVERE, SERIOUS, MODERATE, MINOR,and/or ANONYMOUS levels.
 68. The non-transitory computer usable mediumof claim 61 wherein said message is classified based on urgency level.69. The non-transitory computer usable medium of claim 61 wherein saidmessage is classified based on urgency level, said urgency level furthercomprising IMMEDIATE, URGENT, NEED SOON, INFORMATIONAL ONLY, and/orANONYMOUS levels.
 70. The non-transitory computer usable medium of claim61 wherein said message is classified based on a specific menu selectionfrom said source user interface.
 71. The non-transitory computer usablemedium of claim 61 wherein said message is classified based on aspecific menu selection from said source user interface, said messageclassification further comprising LIFE CRITICAL/MISSION CRITICAL,CRITICAL, URGENT, CORRECTIVE ACTION/AUDIT, CONTINUOUSIMPROVEMENT/SUGGESTION, INFORMATION TRANSFER, and/or ANONYMOUSREPORTING.
 72. The non-transitory computer usable medium of claim 61wherein said message is encrypted by said source messaging clientprocess.
 73. The non-transitory computer usable medium of claim 61wherein said message is encrypted when stored on said message database.74. The non-transitory computer usable medium of claim 61 wherein saidmessage is decrypted by said target messaging client process.
 75. Thenon-transitory computer usable medium of claim 61 wherein saidpredetermined time is set individually for each of said target systeminterfaces.
 76. The non-transitory computer usable medium of claim 61wherein said predetermined time is based on calendar-based information.77. The non-transitory computer usable medium of claim 61 wherein thetransmission of said message to said target system interface issequentially prioritized via use of a hierarchical target messagethread.
 78. The non-transitory computer usable medium of claim 61wherein said source messaging client process receives conditionalbranching requirements for said target system interface via said sourcemessaging system interface.
 79. The non-transitory computer usablemedium of claim 61 wherein said message host process further comprisesanticipatory message queuing wherein said message is sent to said targetsystem interface and the next target system interface addressed by ahierarchical target message address list with information indicatingthat said next target system interface is to wait to process saidmessage until instructed to do so by said message host process.
 80. Thenon-transitory computer usable medium of claim 61 wherein said targetsystem interface is polled to determine if it is online/available, andif not, said target system interface is skipped and the next targetsystem interface addressed by a hierarchical target message address listis utilized as the new target for delivery of said message.